rcwz.pl

Talos: recovering from broken network interface

Sat, 01 Nov 2025 23:00:00 +0200

While playing with my homelab Talos cluster, I accidentaly broke the network interface. As my Raspberry Pi has only one interface, that meant that my device was unreachable over the network. To make matter worse, the node I broke was the control plane, and I wanted to preserve as much data as possible.

To recover from this situation, I was left with no other option, but to boot the device from an SD card. When Talos is installed and first boots up, it creates a couple of partitions on the install disk (nvme0n1 in my case):

Setting up ArgoCD for continuous deployment

Wed, 15 Oct 2025 20:00:00 +0200

In the previous blog post in this series, I added secret management with External Secrets Operator and 1Password Connect. This was a necessary step before introducing ArgoCD, which will automate the deployment of applications to my Kubernetes cluster. Without ESO, I would either have to commit secrets in Git (not ideal, unless you plan to use Sealed Secrets or SOPS) or to manually create secrets in the cluster.

Today, I will set up ArgoCD and migrate all components deployed so far to it. ArgoCD is quite powerful, but I’m going to keep it simple for now, since I wouldn’t be able to use all the features just yet.

Managing secrets with 1Password and External Secrets

Mon, 13 Oct 2025 18:00:00 +0200

So far in this series, I’ve been putting secrets in 1Password vault and creating secrets with a bootstrap.nu script that reads them from 1Password and creates Secret resources in the cluster (using kustomize).

In this post, I’ll add proper secret management to my Kubernetes cluster. I’ll be using 2 components:

1Password Connect for syncing secrets from 1Password and exposing them via an in-cluster REST API,
External Secrets Operator for syncing secrets from 1Password Connect to Kubernetes secrets.

This setup will allow me to create ExternalSecret resources in the cluster that contain references to secrets in 1Password vault. From these, Secret resources will be automatically created and kept in sync.

Adding Cilium to a Talos cluster

Wed, 08 Oct 2025 23:00:00 +0200

In today’s post, I will document how to install Cilium on a Talos-managed Kubernetes cluster. Cilium is going to replace the default Flannel and kube-proxy.

As always, you can find all code in my homelab Git repository and all changes in this post are in this commit.

Prerequisites

My cluster was created in the previous post. While most steps should be applicable to any Talos cluster, some steps may reuse files created in the previous post. If you haven’t set up a Talos cluster yet, please refer to the first post in the series.

Installing Talos on Raspberry Pi 5

Sat, 04 Oct 2025 18:10:00 +0200

A few months ago, some smart folks have figured out patches required to make Talos work on Raspberry Pi 5. As Talos is my favorite Kubernetes distro, I’ve been waiting for this moment for a long time. In this post, I’ll share all steps required to get Talos up and running on Raspberry Pi 5.

Before we begin, you can find all files from this blog post in my homelab repository, specifically commits b0f7125 and 2485555.

A case against migration files

Thu, 03 Apr 2025 18:50:00 +0200

I never really understood the popularity of migration files. Sure enough, you need to somehow change schema from version A to version B and using SQL statements is the most straightforward way to do it, but surely, there has to be a better way, right..?

What if I told you… you don’t actually need migration files to manage your database schema — and your life would be way easier without them? No, I’m not advocating for an ORM.

Proxying WebSocket connections in Go

Sat, 08 Mar 2025 03:00:00 +0200

Golang’s net/http package provides built-in support for http_proxy and https_proxy. This is awesome when developing apps locally, because one can use a tool like Proxyman to watch the traffic.

In a side project, I needed to use a WebSocket client. I used github.com/gobwas/ws and while proxy is not supported out of the box, it was very easy to add using golang.org/x/net/proxy which supports SOCKS5.

Here’s the snippet:

package main

import (
	"context"
	"fmt"

	"github.com/gobwas/ws"
	"golang.org/x/net/proxy"
)

func main() {
	dialer := ws.Dialer{
		NetDial: proxy.Dial,
	}

	conn, reader, _, err := dialer.Dial(context.Background(), "wss://example.org/ws"))
	if err != nil {
		fmt.Fatal("connect to WebSocket server", err)
	}

	// ...
}

Make sure to run your app with ALL_PROXY env var (all_proxy will work too):

Manage Go tools with Go

Fri, 21 Jul 2023 17:00:00 +0200

In almost any code, there comes a time when you need to use external tools for certain functionality. For example, you may want to use golangci-lint to lint your code, generate mocks with mockgen, or run your DB schema migrations with sql-migrate.

There are few ways to achieve this: some projects use Makefile to install dependencies, some other use docker compose and run tools by running containers with mounted volumes.

Today, I want to share a method that is known within Go community, but is still not frequently used.

I'm really bad at side projects

Fri, 21 Apr 2023 17:00:00 +0200

I like side projects. Basically, my whole life is a side project after a side project after a side project. You’d think by now I must be some kind of a side project ninja, but no… I almost never finish them.

Before we dive deeper why I rarely finish my side projects, I want you to understand what a side project means to me, as you may have a different definition. It’s a project that I work consistently on for at least few days. It does not need to become public one day nor it needs to become a potential revenue stream. Oftentimes, side projects are just about learning stuff that I consider interesting.

Kubernetes is hard

Sun, 26 Mar 2023 16:21:00 +0200

Recently, 37signals unveiled mrsk, a tool developed internally to ease with deployments of their services and an accompanying blog post which sparked a lengthy discussion on Hacker News.

Is Kubernetes hard?

Many commenters in the HN thread argued that Kubernetes is complex and I think they are partially right.

Part of the complexity lies in it’s versatility, after all, you can run almost any workload on Kubernetes. That versatility means that resources must be composable. In other words, they must be like Lego, when you can join multiple pieces to build something meaningful. Take containers: in Kubernetes you don’t run containers on their own. Kubernetes has a concept of Pods - a group of one or more containers tighly coupled. But even with Pods, you are quite unlikely to run them on their own. You will usually run them via a Deployment, DaemonSet or a StatefulSet. That’s before you’ve even exposed the service to the outside world.