Fast-Kubernetes: Kubernetes Tutorial, Sample Usage Scenarios (Howto: Hands-on LAB)
I want to share the K8s tutorial, cheatsheet, and usage scenarios that I created as a notebook for myself. I know that K8s is a detailed topic to learn in a short term, I gathered useful information and create sample general usage scenarios of K8s.
This repo covers Kubernetes objects' and components' details (Kubectl, Pod, Deployment, Service, ConfigMap, Volume, PV, PVC, Daemon sets, Secret, Affinity, Taint-Toleration, Helm, etc.) fastly, and possible example usage scenarios (HowTo: Hands-on LAB) in a nutshell. Possible usage scenarios are aimed to update over time.
Tutorial Link: https://github.com/omerbsezer/Fast-Kubernetes
Extra Docker-Tutorial Link: https://github.com/omerbsezer/Fast-Docker
Quick Look (HowTo): Scenarios - Hands-on LAB
- LAB: K8s Creating Pod - Imperative Way
- LAB: K8s Creating Pod - Declarative Way (With File) - Environment Variable
- LAB: K8s Multicontainer - Sidecar - Emptydir Volume - Port-Forwarding
- LAB: K8s Deployment - Scale-Up/Down - Bash Connection - Port Forwarding
- LAB: K8s Rollout - Rollback
- LAB: K8s Service Implementations (ClusterIp, NodePort and LoadBalancer)
- LAB: K8s Liveness Probe
- LAB: K8s Secret (Declarative and Imperative Way)
- LAB: K8s Config Map
- LAB: K8s Node Affinity
- LAB: K8s Taint-Toleration
- LAB: K8s Daemon set - Creating 3 nodes on Minikube
- LAB: K8s Persistent Volume and Persistent Volume Claim
- LAB: K8s Stateful Sets - Nginx
- LAB: K8s Job
- LAB: K8s Cron Job
- LAB: K8s Ingress
- LAB: Helm Install & Usage
- Kubectl Commands Cheatsheet
- Helm Commands Cheatsheet
Table of Contents
- Motivation
- What is Kubernetes?
- Kubernetes Architecture
- Kubernetes Components
- Installation
- Kubectl Config – Usage
- Pod: Creating, Yaml, LifeCycle
- MultiContainer Pod, Init Container
- Label and Selector, Annotation, Namespace
- Deployment
- Replicaset
- Rollout and Rollback
- Network, Service
- Liveness and Readiness Probe
- Resource Limit, Environment Variable
- Volume
- Secret
- ConfigMap
- Node – Pod Affinity
- Taint and Toleration
- Deamon Set
- Persistent Volume and Persistent Volume Claim
- Storage Class
- Stateful Set
- Job, CronJob
- Authentication, Role-Based Access Control, Service Account
- Ingress
- Dashboard
- Play With Kubernetes
- Helm: Kubernetes Package Manager
- Kubernetes Commands Cheatsheet
- Helm Commands Cheatsheet
- Other Useful Resources Related to Kubernetes
- References
8 comments · 98% upvoted · other discussions
This is quite an extensive overview - definitely plan to reference it along with the official docs :)
I've got a quick question I'm inserting in here because I'm lazy & greedy & also hoping other are curious too :p
And a comment I think may help your documentation!
Question:
I'm looking to start kubernetes but haven't yet cause I know it'll be "an event". Part of the end goal of my kubernetes setup is to have a Highly-Available control plane. Is the control plane ephermial? That is to say, is it like Docker where I can tear down a kubernetes cluster (including control plane) and reconstruct it later without any "risk/damage/change/whatever"?
Comment: You insert the below quote a few times, and rightfully so--it's a great quote. But at the same time it would be useful if you could help break it down for noobs. It took me a long time to figure out what kubernets really is, and this quote doesn't help if you're a noob >_<
"Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available." (Ref: Kubernetes.io)
Kisele0n 2 points · Feb 2022
Kubernetes is a container orchestration tool. So you can say "Hey, I've got six computers that I want to run some applications on."
So, you add each computer as a node on the cluster (this is perhaps a little oversimplified, I don't want to get into the control plane side here), and then you can tell the cluster at large "hey, I've got this docker container that I want to be running at all times. And for HA, let's have it run three of them at once."
For what it's worth, I use k3s (a lightweight version of kubernetes, which is often abbreviated k8s). I use an ansible playbook (k3s-ansible, you can find it on github) to connect to each of my nodes, get them set up from scratch, and form up as a cluster.
Then I have a .yaml file for each of the deployments I have running in my cluster (currently mosquitto, zigbee2mqtt, and zwavejs2mqtt with more coming soon). I added some parts to the ansible playbook to start up the deployments, so with one command I can completely destroy the cluster, and with one command I can recreate it and start my deployments (and in fact, I do so occasionally to make sure I haven't made changes somewhere and forgot to update the ansible playbook).
I got started with k3s and k3s-ansible from a post on Jeff Geerling's blog, and I highly recommend looking him up for some well written blogs on kubernetes and other topics.
Psychological_Try559 2 points · Feb 2022
Awesome, I appreciate the breakdown :) Definitely answers the first question!
My concern with k3 is that I have no interest in running containers directly on the host, I much prefer the isolation between VMs. It seems Kubernetes is fine with VMs "you just use kubevert". But I'm not sure how that works with K3.
Also--Geerling's name has come up enough I'm starting to wonder if it's a cult ;)
(I fully intend to check out his stuff too, actually I've seen some of it already & it was great)
Kisele0n 2 points · Feb 2022
Looks like k3s works with kubevirt VMs based on there being a guide for it: https://charlottemach.com/2020/11/03/windows-kubevirt-k3s.html
I honestly have very little need for VMs personally though, so I love just throwing containers at my cluster and then not having to worry about them anymore. If a node goes down it'll failover to another node and keep going on the same IP, so my other services won't even notice.
I have a pi 4 as my control plane for now (cluster currently consists of 2 pis and an old laptop 😅), looking forward to having a proper control plane eventually where I don't have a single point of failure there.
Honestly, I've probably (definitely) just complicated what should have been a simple setup in the name of learning kubernetes (and soon I'll add some helm in there too). I could very easily have just spun up some docker containers on one device and called it good, but with the caveat of "if this one device fails, all those services are now unavailable." Which, I mean, I could just spread the containers out over many devices and then I'd have basically the same thing as I do now, but without the failover and I'd have to manage where each thing goes manually.
MaxHedrome 1 points · Feb 2022
That's why k3OS exists
MaxHedrome 1 points · Feb 2022
"Kubernetes is a portable" - works most places
"extensible" - has plugins and shit, this is important in a minute.
"open-source platform for managing containerized workloads and services" - you're still using docker, except the kubernetes community has bailed on docker and are now trying to standardize around containerd (no daemon - explicit container starts?)
"that facilitates both declarative configuration and automation." - your yamls are called helm
"It has a large, rapidly growing ecosystem." - there's a ton of awesome things out there! There's a ton of half baked shit out there!
"Kubernetes services, support, and tools are widely available."
re: extensible... philosophically, kubernetes is a botnet to manage all of your services, in a highly available, fast update lifecycle, across physical nodes, and possibly datacenters slash clouds.
You are trading your docker-compose files for helm manifests and a different approach at the full lifecycle of application management. It is a better swarm, but it is also a beast if you do not dedicate yourself to it.
I mostly still piddle around with a lot of my compose servers running, because they just work. I don't need that scalability or development speed.
Full kubernetes mastery consists of a hard shift into sysadmin land.
Plus there are also things like hashi's Nomad, that kind of take a much smaller scale approach to that same kubernetes philosophy.
And that's the important takeway imo. Kubernetes philosophy is what makes it extensible.
There are a chain of things in a kubernetes cluster that need to happen. It doesn't always necessarily matter which part you use (some are most definitely better than others), but many of the engine parts can be swapped out for other pieces that have been built by other groups.