Hello friends!
It's time for the traditional round-up of all things Linux, Containers, Kubernetes, and Server-Side craft π§
I've got a lot of stuff to share with you this month, so without any further ado, let's get started!
I started October with preparations for my first Kubernetes 101 workshop. It was supposed to be about Pods, Services, EndpointSlices, and the like, but, as often happens, I found myself pulled in a slightly different direction...
What if you don't start from Pods, Deployments, and Service and instead take a step back and look at how things were done in the past with good old VMs? Can it help understand Kubernetes faster and deeper? In the end, I got so excited about this idea that the workshop video got a supporting long-form blog post:
In the blog post, I start by showing how to run a single instance of the (containerized) app on just one server, then show how to replicate and scale the app instances, organize the load balancing, and even touch upon zero-downtime deployments, failure recovery, and service discovery. The main idea is to show how the level of automation complexity increases at every stage of the service architecture evolution. After the problem set and the "traditional" solutions become clear, I show how Kubernetes takes infrastructure management to the next level by packaging all of the above (and then some more) infra patterns into single-line commands.
Kinda cool, especially when you already know how to use Kubernetes, don't have to manage the clusters, and the infrastructure bills are paid by your employer.
What about those of us who truly love servers and/or care about the infra bills? Did you know that auctioned servers on Hetzner are x10 cheaper than metal EC2 instances, and the maintenance costs of the low-scale fleet of servers are usually exaggerated? Speaking from experience π
This LB+Docker+Traefik+Ansible (or Capistrano) setup that I was trying to demo in the first part of the above blog post is actually pretty typical. I've set up variations of it several times in my career, so I was pleasantly surprised to discover that DHH and 37signals folks created a tool called Kamal that does pretty much the same thing.
Kamal, formerly known as MRSK, is a relatively new piece of infra software with a simple but powerful idea - if you know Linux (a bit) and Docker (slightly more than a bit), then running a bunch of containers by broadcasting vanilla SSH commands to a handful of VMs might be everything you need.
I spent some time playing with Kamal, and here is what I found:
Overall, I liked the tool, but I'd like the load balancing and service discovery automation to be eventually covered, too. Here is a new multi-node iximiuz Labs playground where you can experiment with Kamal π§βπ¬
The Kubernetes workshop and my Kamal experiments made me finally find time (and excuse) to finish the multi-node playground support. The labs were designed to be multi-node from day one, but a few things were still missing.
Since October, the following multi-VM playgrounds have become available:
Another (significant) quality of life improvement that I'm particularly proud of is that every playground now gets an accompanying short-lived container registry that is accessible on the "fake" registry.iximiuz.com address (which resolves to 192.168.1.2). This makes sharing images between playground VMs so much easier β€οΈβπ₯
One more playground that made it to iximiuz Labs in October is a preconfigured Zig (programming language) dev environment - it's a VM with a loaded VS Code, Docker, and other batteries included. This language keeps popping up on my radar, and the code snippets that I've seen so far look pretty sleek.
Last but not least, kexp - the visual Kubernetes Explorer is closing in on 500 stars on GitHub (in just one month of its existence π), and it also got a few features shipped this month:
βA kind reminder that you can support my OSS work and the development of iximiuz Labs by becoming a patron. In addition to my gratitude, you'll also get:
βA Comprehensive Guide to API Gateways, Kubernetes Gateways, and Service Meshes - This is a very good read on the mentioned tech. If youβve been confusing API Gateways, Ingress Gateways, Kubernetes Gateway API, and Kubernetes Ingress - itβll definitely help sort things out. I particularly liked the narrative - start from the basic concepts (what is an API Gateway) and then connect the dots with the corresponding Kubernetes abstractions (Gateway API and Ingress). Also, itβs heavily illustrated. Do recommend!
βSticky sessions and canary releases in Kubernetes - A brief, colorful post by Daniele Polencic on how Nginx Ingress Controller implements sticky sessions. There is also an interesting plot twist - turns out you can leverage sticky sessions for doing canary releases. The only bit thatβs missing in this wonderful blog post is the practical part. Luckily, you can compensate for it with my K3s playground π
βUser Namespaces: Now Supports Running Stateful Pods in Alpha! - Kubernetesβ support of User Namespaces keeps improving. The article also has a handy ~6m video demoing how simple it is to break out of a container. One more time - containers are security means.
βWhy do Kubernetes Control Planes have an odd number of members? - A fun fact you may learn from the article: a cluster with two control plane nodes is actually less reliable than with one. A good first principle thinking explanation.
βWhat happens when β¦ Kubernetes edition! - A solid read but could definitely use some illustrations π¨
βStructured Logging with slog - The biggest Go addition since generics, probably. Finally, a standard structured logger implementation. I took a brief look, and the design seems to satisfy all my needs from a logger. Glad to see it shipped!
βRedis Explained - One piece of high-quality content with a ton of visuals.
βStacked Diffs (and why you should know about them) - Iβm surprised by how low awareness of this technique is among developers outside of FAANG. The idea is that you do smaller PRs and donβt wait until the previous PR is merged, even if the next code change depends on the change in the previous PR - you just branch out of the previous branch and, when ready - publish another PR, diffing it with its parent branch, and not the trunk. Stacked MRs/PRs/Diffs unblock you and also simplify lives for reviewers. The downside is that a stacked sequence of PRs might be a pain to maintain (rebases have a ripple effect), but the idea is to simplify the reviewerβs life to get the PRs merged faster. Plus, the tooling matters.
βThe Inner-Platform Effect by Matt Rickard - If youβre building an internal platform, this short blog post combined with this sentiment by Justin Garrison will luckily make you think. But don't think too much - there are always folks on the other end of the spectrum, like DHH shipping Kamal in 2023 π
βAnticipate the Cheap - A short, enjoyable story and a business lesson. Extreme achievements require an extreme amount of confidence and boldness.
The space calms down a bit, and some good LLM resources start emerging in my feed - Simon Willisonβs Weblog and One Useful Thing substack newsletter.
Is it a new record? Probably yes :) Hope you enjoy this issue, and have a creative week ahead!
Cheers
Ivan
Building labs.iximiuz.com - a place to help you learn Containers and Kubernetes the fun way π
Hello π Ivan's here with a slightly delayed September roundup of all things Linux, Containers, Kubernetes, and Server Side π§ What I was working on This month, I worked on an assorted set of topics. Skill Paths First off, the skill paths! I finally finished the underlying machinery, and now iximiuz Labs supports a new type of content - short roadmaps that you can use to develop or improve a specific skill: how to debug distroless containers, how to copy images from one repository to another,...
Hello friends! Ivan's here with another monthly roundup of all things Linux, Containers, Kubernetes, and Server Side π§ The issue's main topic is iximiuz Labs' largest-ever upgrade: Fresher and more streamlined look of the frontend UI π A new 5.10 Linux kernel built with nftables support (finally, we can try out kube-proxy's nftables mode). New default playground user - laborant (yep, rootless containers learning for). New playgrounds: Ubuntu 24.04, Debian Trixie, Fedora, and Incus (yay! more...
Hello friends! Ivan's here with a slightly delayed July roundup of all things Linux, Containers, Kubernetes, and Server Side π§ What I was working on This month, I got nerd-sniped by cgroups. It all started when I ran into a pretty significant difference in how Docker and Kubernetes handle the OOM events. When you limit the memory usage of a multi-process Docker container, the OOM killer often terminates only one of the processes if the container runs out of memory. If this process is not the...