OK, We are talking Kubernetes here.

Intro

If you’re reading this, it’s obvious you’ve been directed here from one of my posts. You’re likely curious about which Kubernetes setup I used to demonstrate a specific step or procedure.

The short answer like the description says - It’s mostly Minikube 😎. (still reading ?)

Ok then. To keep my project posts focused on application logic and deployment strategies, I’ve centralized the details of my underlying infrastructure here. Whether I’m running a quick local test or stress-testing a high-availability cluster, this is the ‘source of truth’ for my environment.

My Infrastructure Environments

I maintain several environments depending on the complexity and the goals of the project.

The “How-To” of Context Switching

I maintain a clean workspace by utilizing kubectl context switching. It allows me to jump seamlessly between my local Minikube and various remote clusters:

# View available contexts
kubectl config get-contexts

# Switch to your desired environment
kubectl config use-context <context-name>

Where It All Started

Like every Newbie, I had that “aha!” moment when a tutorial just clicked. For me, it was this video from NetworkChuck. It provided the solid foundation I needed to dive into the cloud-native world

NetworkChuck is a pretty laidback Youtuber, who’s got an awesome Youtube and Instagram channel, I have to admit I’ve learnt and understood a lot from him. (and yes, I’m still working on matching that beard game. I can’t lie, I lost that battle there LOL).

Standard Tools in My Toolkit

As I explore deployment strategies like Rolling Updates, Blue-Green, and Canary releases, I rely on a standard set of tools to keep everything reproducible:

• WebApps: A custom themed Nginx application on DockerHub designed for testing and demonstration purposes.

• Helm: For templating and managing Kubernetes applications.

• GitLab: For version control and CI/CD pipelines.

• Terraform: For infrastructure-as-code provisioning.

• Nginx: Frequently used as my go-to Ingress controller for testing.

• Ansible: For provisioning, and automanting configuration management

Still Reading ??

If youre not bored and would further like to understand the breakdown of my of my current cluster and also the architeture of kubebernetes, then there are as follows :

My setup

Minikube

• Minikube is a lightweight tool that allows you to run a single-node Kubernetes cluster locally on your machine (Linux, macOS, or Windows), making it ideal for learning, development, and testing without needing cloud resources. It operates by creating a virtual machine or container using supported drivers such as Docker, VirtualBox, Hyper-V, or KVM, which provides a safe environment to experiment with Kubernetes features like kubectl, dashboard, ingress, and persistent volumes.

LKE on Linode

• Linode Kubernetes Engine (LKE): This is the primary managed service where Linode handles the control plane maintenance. Users can deploy clusters via the Cloud Manager, API, or integrated with Rancher for a GUI-based management experience. LKE supports features like node pools and autoscaling.

GKE on GCP

• Google Kubernetes Engine (GKE) is Google Cloud Platform’s managed service for running Kubernetes, handling the operational overhead of the control plane while allowing users to focus on application deployment and scaling. It offers deep integration with GCP services like Cloud Storage, BigQuery, and Stackdriver, providing advanced security features such as VPC-native clusters and automated vulnerability scanning. K3s on AWS

Other thoughts, if youre new to Kubernetes and would love to know other avenues one can have a kubernetes cluster setup are as follows :

📋 Overview of The Kubernetes Architecture

The 5 components of kubernetes

Kubernetes is a distributed system composed of two main components: the Control Plane and the Data Plane (Worker Nodes).

Control Plane Components

The Control Plane manages the cluster’s state and orchestration.

• API Server (kube-apiserver): The front-end for the Kubernetes control plane, handling all API requests and acting as the central management point.
• etcd: A distributed key-value store that serves as the single source of truth for cluster data, storing configuration, state, and metadata.
• Scheduler (kube-scheduler): Assigns pods to worker nodes based on resource availability, policies, and constraints.
• Controller Manager (kube-controller-manager): Runs controllers that handle routine tasks like node monitoring, replication management, and endpoint provisioning.
• Cloud Controller Manager (optional): Integrates Kubernetes with cloud provider APIs (e.g., AWS, GCP) for load balancers, storage, and networking.

Worker Node Components

The Worker Nodes execute workloads.

• Kubelet: The primary agent on each node, responsible for ensuring containers in pods are running and healthy.
• Kube-proxy: Manages network rules on each node to enable communication with pods, supporting service discovery and load balancing.
• Container Runtime: Software (e.g., Docker, containerd, CRI-O) that runs containers within pods.

Core Abstractions

• Pods: The smallest deployable units, containing one or more containers that share storage and network.
• Services: Abstracts a set of pods with a stable IP and DNS name for reliable access.
• Deployments: Define the desired state for pods and ReplicaSets, enabling declarative updates.

These components work together to maintain the desired state of the cluster, enabling automated deployment, scaling, and management of containerised applications.

📌 Simple Types of Kubernetes Clusters

1. By Management & Location

• Self-managed – You install, run, and update everything yourself (on your own servers or VMs). Full control, more work.

• Cloud-managed – Cloud provider runs the control plane; you only manage your apps/nodes. Less work, integrated cloud tools.

• Hybrid – Runs across on-premises + public cloud. Keep sensitive data local, scale to cloud when needed.

• Multi-cloud – Runs across two or more public clouds (e.g. AWS + Azure). Avoid lock-in, use best features from each.

• Edge – Small, lightweight clusters at remote locations (shops, factories, devices). Low latency, works offline.

2. By Size & Availability

• Single-node – One machine = control plane + worker. For learning/dev only.

• Multi-node standard – Separate control plane + workers. Basic production setup.

• High Availability (HA) – 3+ control plane nodes. If one fails, others take over. Recommended for production.

3. By Distribution

• k3s – Tiny (<100MB), for edge/IoT.

• MicroK8s – Lightweight, simple, for dev/edge.

• OpenShift – Enterprise-grade, extra security/tools.

• Charmed Kubernetes – Automated, works everywhere.