Skip to content

DevOps

GPUs on Kubernetes: From Bare Metal to Schedulable in One Operator

A fresh Kubernetes cluster has no idea your nodes have GPUs. kubectl describe node shows CPU, memory, and pods — nothing else. To make a pod request a GPU you need a driver, a container runtime hook, and a device plugin advertising the hardware to the scheduler, all version-matched across every GPU node. Do it by hand and you'll re-do it on every kernel bump. This post wires it up the way you actually want — one operator — and works on any Kubernetes, not a specific vendor's distro.

Stacking MIG and Time-Slicing on One GPU Operator values.yaml

MIG carves a GPU into hardware-isolated slices. Time-slicing oversubscribes each slice so more pods can share it. Stack them and one physical GPU advertises far more schedulable units than it has silicon — useful when you have more workloads than GPUs and most of them sit idle. Here's the exact values.yaml, wired into the kommander-applications GPU Operator 26.3.0 app1, and the labels that switch a node between layouts.

Cilium and eBPF: the Networking Layer Under Your Cluster

Your cluster routes every packet through iptables, and at a few thousand Services that chain becomes a linear scan the kernel walks per connection. Cilium throws that out and runs networking, policy, and observability as eBPF programs in the kernel instead — no sidecars, no iptables, no agent in the data path. This post walks the whole stack: how a packet even finds another pod, installing Cilium as a kube-proxy replacement, watching real traffic with Hubble, locking the cluster down with identity-based policy, stretching it across clusters with Cluster Mesh, and dropping the service-mesh sidecars — all copy-paste.

Centralize Log Solution with the Elastic Stack

Use case: ship Kubernetes ingress logs off the cluster into a self-managed Elastic Stack on Ubuntu servers, parse them, and keep them searchable for 90 days without blowing the disk budget. The Elastic Stack handles this cleanly, and the 2026 build leans on four current features that older tutorials skip: LogsDB, ILM, data streams, and a Kubernetes-native shipper.

  • in DevOps
  • 5 min read

Git Workflow for Release Management: Branches vs Tags

Most teams invent their Git strategy as they go. One developer starts tagging releases. Another uses branches. A third creates a hotfix branch and never deletes it. By the time you need to patch a six-month-old release, nobody remembers what release-final-v2 means or where hotfixes actually landed.

A clear branching strategy prevents this. This post covers a battle-tested Git workflow built around two parallel approaches — version control with branches and version control with tags — and tells you exactly when to use each.

  • in DevOps
  • 16 min read

DevOps Project Example: From Code Push to Production with GitOps, FluxCD, and Kubernetes

Most DevOps tutorials show you a pipeline diagram. This one shows you a real pipeline, built on a real application, running on real Kubernetes clusters — with every tool, every workflow, and every design decision explained.

This post walks through the complete CI/CD system behind Slotmachine — a real-time multiplayer tournament app — from the moment a developer pushes code to GitHub, through six security and quality gates, all the way to automated deployment on both Nutanix on-premise clusters and AWS EKS. No hand-waving. No "and then magic happens."

The full source code is available in two repositories:

  • in DevOps
  • 8 min read

Cloud Engineer vs DevOps vs SRE vs Platform Engineer: Who Does What?

You're browsing job boards and you see four different titles: Cloud Engineer, DevOps Engineer, Site Reliability Engineer, Platform Engineer. The salaries are similar. The required skills overlap. Some listings seem interchangeable.

Are these the same job? Is one better than the others? Which should you aim for?

They are not the same job — but they are deeply related, and the confusion is completely understandable. Each role grew from a different pain point in how software gets built and run, and in 2026, all four exist inside most engineering organizations at the same time.

  • in DevOps
  • 24 min read

Engineering Standards for DevOps: The Complete Guide

A team without standards is a team that reinvents everything — every time, in every project. Standards are not bureaucracy. They are the codified answers to questions your team has already solved, so you can spend your energy solving new ones.

This guide covers thirteen engineering standards that separate high-performing DevOps teams from the rest. For each standard, we go beyond the "what" to explain the "why" and the "how" — with concrete tooling, configuration examples, and the decision frameworks you need to implement them in your organisation.