K3S: Core Kubernetes Concepts

Understanding Kubernetes Workloads#

Kubernetes workloads are like the chaotic team members of a tech startup—each one has a specific job, but sometimes they crash, restart, and mysteriously consume more resources than expected. Let’s break them down.

Introduction to Kubernetes Objects#

Kubernetes objects are the building blocks of any cluster. They define what runs, how it runs, and where it should run. Think of them as little digital employees that don’t need coffee but do need careful management.

Pods: The smallest deployable unit in Kubernetes#

A Pod is like a cozy apartment for your containers. It can hold one or more containers that share storage and networking. If a Pod dies, Kubernetes just spawns a new one like some sort of container phoenix.

Deployments: Managing replica sets and rolling updates#

A Deployment makes sure you always have the right number of running Pods. It also lets you roll out updates without breaking everything—at least, in theory.

ReplicaSets: Ensuring high availability of applications#

A ReplicaSet guarantees that a specific number of Pod replicas are always running. Accidentally delete one? No problem. Kubernetes will spawn a new one before you even realize you messed up.

Working with ConfigMaps and Secrets#

Nobody likes hardcoding configuration into an application—unless they enjoy debugging nightmares. Kubernetes provides ConfigMaps and Secrets so we can store configuration externally like civilized people.

What are ConfigMaps and Secrets?#

• ConfigMaps store non-sensitive configuration data (like environment variables).
• Secrets store sensitive information (like passwords) in a base64-encoded format. Spoiler: that doesn’t make them super secure, so be careful.

Creating and managing ConfigMaps#

Because stuffing config values directly into code is a terrible idea:

kubectl create configmap myconfig --from-literal=APP_ENV=production
kubectl get configmap myconfig -o yaml

Creating and using Secrets for sensitive data#

If you’re storing database passwords in plain text, you’re asking for trouble. Use Secrets instead:

kubectl create secret generic mysecret --from-literal=DB_PASSWORD=mysecurepassword
kubectl get secrets mysecret -o yaml

But please, don’t commit these to GitHub. Just don’t.

Role of Namespaces in Kubernetes#

Kubernetes Namespaces let you organize resources like a pro. Imagine a messy office—Namespaces are like separate rooms that keep different projects from getting tangled up.

Why use Namespaces?#

• Avoid resource conflicts
• Isolate environments (dev, test, prod)
• Keep your cluster from turning into an unmanageable mess

Creating and managing Namespaces#

Setting up a Namespace is as easy as:

kubectl create namespace dev
kubectl get namespaces

Deploying resources to specific Namespaces#

Keep your workloads organized:

kubectl run myapp --image=nginx --namespace=dev

Basic kubectl Commands for K3s Cluster Management#

Memorizing kubectl commands is a rite of passage for Kubernetes users. Here are some essentials:

Listing all resources in the cluster#

kubectl get all

Because sometimes you just need to see what’s running (and what’s mysteriously missing).

Viewing logs of a running container#

kubectl logs -f myapp

Useful for debugging when everything is on fire.

Describing Kubernetes objects#

kubectl describe pod myapp

Gives you a detailed breakdown of what’s happening inside a Pod.

Deleting resources#

When things go wrong (and they will), you can clean up:

kubectl delete pod myapp

Hands-On Exercise#

Enough theory—let’s get our hands dirty.

• Create a ConfigMap and use it inside a Pod
• Deploy a simple application using a Deployment and ReplicaSet
• Secure an application using a Secret for database credentials
• Manage resources using kubectl commands

Once you’re done, you’ll officially be on your way to mastering Kubernetes—without the usual headache. 🚀