In this article we want to explore options on how to create a Kubernetes cluster where we can deploy our application(s).
Nodes in Kubernetes cluster can be virtual machines running on a local host, on-prem servers or in the cloud and also they can be bare metal machines, or mix of both.
Kubernetes Distributions
To create Kubernetes cluster we have a choice of various Kubernetes distributions which all have their own features, benefits and drawbacks. In general, they can be grouped as:
- non-hosted solutions (require manual installation and setup of the tools and the cluster)
- Minikube
- non-production only
- only on a local machine
- out of the box spins up a single-node Kubernetes cluster, with no scaling available but it also supports a multi-node clusters
- relies on virtualization (VirtualBox, Docker)
- an official mini distribution for local testing and development (run by the same foundation as K8s)
- MicroK8s
- on a local machine
- single- or multi-node Kubernetes cluster
- run and maintained by Canonical (Ubuntu maintainers)
- easy to install on Ubuntu (snap package)
- easy to install addons (ingress, registry, local access (files and services), certmanager)
- addons are just helm charts
- Kubeadm
- production-grade
- the official CNCF (Google Cloud invented Kubernetes and open sourced in 2014; Cloud Native Computing Foundation took over its development and maintenance) tool for provisioning Kubernetes clusters
- a "full" Kubernetes
- gives you a standard Kubernetes cluster (i.e. standard components that make up Kubernetes)
- on a local and remote machines
- supports multi-node clusters
- tool for provisioning Kubernetes clusters in a variety of shapes and forms (e.g. single-node, multi-node, HA, self-hosted
- the most manual way to create and manage a cluster
- K3s
- lightweight Kubernetes
- still a full Kubernetes distribution
- supports single- or multi-node clusters
- currently does not support High Availability (HA = running multiple master nodes)
- suitable for edge environments, IoT devices, CI pipelines, ARM devices (Raspberry Pi)
- replaces docker with containerd
- uses sqlite3 as the default DB (instead of etcd)
- Traefik installed by default (for ingress)
- Kind (Kubernetes-in-Docker)
- runs Kubernetes clusters in Docker containers
- supports multi-node clusters
- supports HA clusters
- optimized first and foremost for CI pipelines
- Desktop Docker
- Docker Desktop now ships with a bundled Kubernetes
- Kubernetes versions are tightly coupled with the Docker version
- K3d
- K3s-in-Docker
- Kubespray
- https://github.com/kubernetes-sigs/kubespray
- hosted solutions (tools and cluster creation are out of the box):
- Amazon AWS: Amazon EKS (Managed Kubernetes Service)
- Google Cloud (GCE): Google Kubernetes Engine (GKE)
- Microsoft Azure Kubernetes Service (AKS)
- DigitalOcean Managed Kubernetes
- Hetzner (German hosting company with data centres)
- OpenStack (open source cloud computing infrastructure software project )
- and many more...
Scaling
Scaling is a process of adding more processing power to the Kubernetes cluster so it can meet the demands of the current workload. There are two types of scaling:
- vertical (also known as "scaling up")
- assigning more resources (for example: memory or CPU) to the Pods that are already running for the workload
- adding more power to your current machines e.g. upgrading the CPUs and/or memory
- horizontal
- the response to increased load is to deploy more Pods
- adding additional nodes
- adding a virtual machine to a cluster of virtual machine clusters or adding a database to a database cluster
- In Kubernetes, you can automatically scale a workload horizontally using a HorizontalPodAutoscaler (HPA). It is implemented as a Kubernetes API resource and a controller and periodically adjusts the number of replicas in a workload to match observed resource utilization such as CPU or memory usage
- Horizontal scaling of DB systems may require application architecture and code changes due to the distributed nature of the data.
- Database systems that are scaled horizontally can be more complicated to manage and maintain, leading to more work
Horizontal scaling is a good choice when you need to handle high traffic volumes, while vertical scaling is more suitable for complex tasks that require greater processing power.
To continue your Kubernetes learning journey, read the next article in these series which explains our Kubernetes distribution of choice (for learning Kubernetes) - Minikube: Introduction to Minikube | My Public Notepad.
No comments:
Post a Comment