← Back to Blog

What Is Kubernetes? An Introduction to the Best Open-Source Automation Platform Today

Kubernetes is an open-source platform that automates the management, scaling, and deployment of containerized applications — which is why it's also called a Container Orchestration Engine.

What is Kubernetes?

Kubernetes Orchestration lets users build application services spanning many containers, schedule those containers across a cluster of servers, scale the containers, and manage their health over time.

Why do we need Kubernetes?

When you actually run containers in production, you can end up creating dozens, even thousands, of containers over time. These containers need to be deployed (across multiple server hosts), managed, connected, and updated. Doing this manually would take an entire team. With Docker, you can create many containers on 1 host. But if you want to use it in a production environment, you'll need to worry about a lot of things, like:

  • Managing multiple Docker hosts at once
  • Orchestrating containers
  • Rolling updates
  • Scaling/Auto Scaling
  • Monitoring container health (still running or not)
  • Self-healing (automatically detecting and fixing errors) when something goes wrong
  • Service discovery
  • Load balancing
  • Managing data, workload, logs
  • Infrastructure as Code
  • Connecting and scaling with other systems

Without K8s, managing all these tasks manually is nearly impossible.

What does the name K8s mean?

"Kubernetes" spelled out has 10 letters, and the name K8s is simply K-8 (the number of letters in between)-s.

Kubernetes architecture and core components

Kubernetes follows a master-slave architecture. The Master node talks to the worker nodes and schedules pods to run on specific nodes.

Master node

Kubernetes' control plane component, making decisions for the cluster (like scheduling), detecting and responding to cluster events (like starting a new pod when a deployment's replica count isn't satisfied).

API server

The API server exposes the Kubernetes API, responsible for syncing info via a REST API, used to place pods onto nodes and receive settings for pods/services/replicationControllers.

etcd

The store holding all the Kubernetes cluster's data, like the cluster's configuration info, representing the cluster's state at any given moment. It can be used to link the settings for each node.

Scheduler

The component responsible for choosing the best node to run a pod on. When a pod is created, the Scheduler decides which node to run it on based on factors including total available resources, the amount of resource allocated to each workload per machine, etc., to make sure there's no overload and the system runs stably.

Controller Manager

The Controller Manager watches and adjusts the cluster's state and performs routine tasks to maintain the desired state. Details of all activity get logged. Example: if a pod stops running, the Controller Manager notices this and launches a new pod to maintain the desired pod count.

Worker node

The server that runs applications. Kubernetes worker nodes host pods, and pods are the application's workload components.

  • Kubelet is a process responsible for communication between the Kubernetes Master and the node; it manages the pods and containers running on a machine.
  • Container runtime (like Docker, rkt) is responsible for pulling container images from a repository, unpacking the container, and running the application.

Pod

A pod usually contains one or more containers to run a specific process, like some piece of software. Pods get created and deleted depending on workload demand. Pods share an IP address and storage space with each other. To find info about a pod, you can run: describe pod PODNAME

Service

In Kubernetes we have the concept of a service, a layer sitting on top of a group of Pods, exposing the applications running on them. A Service groups a set of pod endpoints (IP addresses) together to allow communication without needing to know much about the network structure, solving the difficult problem of communication between microservices, and performing load balancing here.

Since K8s exists to handle hundreds or thousands of containers/services rather than just 1, we'll need a service here.

Here's a simple example of defining a Pod and Service in YAML:

Pod definition

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: my-app
    image: my-app:1.0

---
# Service definition
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

Persistent Volume (PV)

In K8s architecture, we'll need somewhere to store data, since we can't store it on the container — if the container dies, the data goes with it. So data needs to be stored on separate storage. A Persistent Volume (PV) is an allocated amount of storage (allocated by an admin or via Storage Classes), for example 1GB or 10GB, matching the application's needs. Persistent Volume Claims (PVC) are storage requests from the user's side. When a PV satisfies a PVC, the condition is met.

Using a K8s service like Bizfly Kubernetes (BKE) gives you Persistent Volume support. You can check out using a pre-existing volume as a Persistent Volume here: docs.bizflycloud.vn

Network Policies and Ingress

Network Policies provide connection rules to a pod based on label and port, defining who can or can't connect to a port.

Ingress, on the other hand, manages access into services in the cluster from the outside, usually HTTP access.

ConfigMaps & Secrets

ConfigMaps are used to store non-sensitive data as key-value pairs — meaning you can separate parts of a config from the image content (like not storing a password in a config file, for safety), helping containerized applications stay portable.

Secrets are similar to ConfigMaps, but used to store sensitive info like passwords, OAuth tokens, and ssh keys. Storing sensitive info in a Secret is safer and more flexible than putting it verbatim in a Pod definition or a container image.

Concepts for different services:

Deployments provide declarative updates for Pods and ReplicaSets. You describe the desired state in a Deployment, and the Deployment Controller changes the actual state to match the desired state.

StatefulSet is used for workloads that need stable network identity, stable persistent storage, and gentle deployment and scaling. Because it's less flexible this way, this service isn't used as much anymore.

DaemonSet ensures that all (or some) nodes run a copy of a pod. As nodes get added to the cluster, pods get added. As nodes get removed from the cluster, those pods get garbage collected.

What are the benefits of Kubernetes?

1. Efficiency

Even though deploying and updating Kubernetes isn't a trivial task, with the pre-built engines available, running containerized applications with Kubernetes gets massively simplified compared to deploying separate server infrastructure and managing the internal details of operations yourself.

2. Reliability

Kubernetes, with features like load balancer or autoscale, helps maintain stability and availability for applications while they're running.

3. Flexibility

Provides the ability to automatically scale resources to supply applications, meeting the growing scale of a business.

4. Portability

Kubernetes can be deployed across many different cloud environments — public cloud, private cloud, on-premise. For example, BKE supports a K8s Everywhere feature that connects K8s on Bizfly Cloud to one or more other providers, or to K8s on physical infrastructure, letting you flexibly switch between clouds without limiting your development needs.

5. Resource management and security

Kubernetes provides a number of APIs and security controls, as well as ways to define policies helping users build a security management approach.

6. Open source

Kubernetes is developed as open source — previously the fastest-growing open-source software ever. This means there's a massive ecosystem of other open-source tools compatible with K8s. As a result, Kubernetes keeps getting improved continuously, creating outstanding flexibility that keeps users from being tied to outdated technology.

7. A huge support community

Since Kubernetes is the most popular container orchestration tool today, there's an active user community contributing plenty of online reference resources, including info, management tools, and extensions.

8. Support for Docker and many other platforms

Who should use Kubernetes?

  • Kubernetes eliminates a lot of the manual processes involved in deploying and scaling containers. So businesses that need to scale quickly can't afford to skip K8s.
  • Projects that require running >=5 containers for the same type of service.
  • Growing startups investing in tech to make auto-scaling easier down the road.
  • DevOps/Sysadmins wanting to learn and explore.

Comparing Docker with Kubernetes

If Docker is the containerization platform, Docker Swarm is a container orchestration system similar to Kubernetes. Docker Swarm is Docker's own orchestration tool, built directly into its ecosystem.

CriteriaKubernetesDocker Swarm
Deploying applicationsUses a combination of pods, deployments, services (or microservices)Deployed as a service (or microservices) in a Swarm cluster.
InstallationDone manually with a specific plan to ensure it runs effectively.Very simple to install, needs only an optional toolset to build per config and environment.
UsageRequires users to have CLI knowledge to run on Docker.Uses a declarative language within a structure.
AdvantagesStrong automatic scaling ability across environments. Kubernetes has a stronger community than Docker Swarm. Kubernetes has over 50,000 commits and 1,200 contributors.Deploys containers faster than Kubernetes, so response time is faster when environments need to change per demand. However, at a production scale it can't match Kubernetes' capabilities.

The difference between Kubernetes and Docker lies in their purpose and role, but the two can work together to support deploying and orchestrating containers in a distributed architecture. Docker is a platform to build, distribute, and run Docker containers, while Kubernetes is the system that orchestrates those Docker containers.

So the best choice for developers is combining both Docker and Kubernetes to boost software development efficiency.

Real-world applications of Kubernetes

Large-scale application deployment

High-traffic websites and cloud-developed applications can receive millions of requests from users every day.

Fields requiring high-performance computing

Industries like government, science, finance, and engineering rely heavily on high-performance computing (HPC), work that needs to process large amounts of data to run complex algorithms.

AI and machine learning

Building and deploying artificial intelligence (AI) and machine learning (ML) systems requires huge volumes of data and complex processes, similar to high-performance computing and big data analytics.

Microservice architecture

The microservice model breaks an application into many smaller components or services. For example, e-commerce websites are commonly developed using the microservice model.

Enterprise DevOps

The ability to update and deploy applications quickly matters a lot for business success. Kubernetes gives DevOps teams the ability to optimize operations, increasing flexibility across the entire workflow. On top of that, CI/CD increasingly plays a more important role in software development, and Kubernetes plays an important role in cloud-native CI/CD processes thanks to automatically deploying containers across cloud environments and ensuring effective resource usage.

A few frequently asked questions about Kubernetes

1. Can Kubernetes run on any platform?

It can be installed on Windows, macOS, and various Linux platforms.

2. Can I use Kubernetes without using Docker?

Without Docker, Kubernetes can still work with many other container runtimes like RunC, cri-o, etc.

3. How does Kubernetes improve application security?

Kubernetes provides built-in security advantages. For example, application containers usually don't get patched or updated in place — instead, container images get completely replaced with new versions. This enables strict version control and quick rollback if a bug is found in new code.

Have thoughts on this?

I'd love to hear your perspective. Send me a message.

Get in touch