<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Kubernetes on Thalamus</title><link>https://blog.thalamus.am/tag/kubernetes/</link><description>Recent content in Kubernetes on Thalamus</description><generator>Hugo -- gohugo.io</generator><language>en-US</language><copyright>Thalamus TM</copyright><lastBuildDate>Sun, 20 Sep 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://blog.thalamus.am/tag/kubernetes/index.xml" rel="self" type="application/rss+xml"/><item><title>The 200 that nobody received</title><link>https://blog.thalamus.am/posts/the-200-that-nobody-received/</link><pubDate>Sun, 20 Sep 2026 00:00:00 +0000</pubDate><guid>https://blog.thalamus.am/posts/the-200-that-nobody-received/</guid><description>&lt;img src="https://blog.thalamus.am/posts/the-200-that-nobody-received/editorial-cover.png" alt="Featured image of post The 200 that nobody received" /&gt;&lt;p&gt;Clients of &lt;code&gt;api.thalamus.am&lt;/code&gt; were occasionally timing out. The gateway access log showed successful requests.&lt;/p&gt;
&lt;p&gt;The request had arrived. The upstream had answered. The log recorded a 200. There was no obvious pattern by endpoint or time of day, and the failures were rare enough to disappear into otherwise healthy dashboards.&lt;/p&gt;
&lt;p&gt;I spent too long looking for an application error. The useful question turned out to be: which machines did the connection depend on after the application had done its work?&lt;/p&gt;</description></item><item><title>df says full, du disagrees</title><link>https://blog.thalamus.am/posts/df-says-full-du-disagrees/</link><pubDate>Sat, 08 Aug 2026 00:00:00 +0000</pubDate><guid>https://blog.thalamus.am/posts/df-says-full-du-disagrees/</guid><description>&lt;img src="https://blog.thalamus.am/posts/df-says-full-du-disagrees/editorial-cover.png" alt="Featured image of post df says full, du disagrees" /&gt;&lt;p&gt;The third time the compactor volume filled up, I checked what was using the space before making it bigger.&lt;/p&gt;
&lt;p&gt;The alert was &lt;code&gt;KubePersistentVolumeFillingUp&lt;/code&gt;, on the compactor volume of our log store. The first time, we resized the volume. That bought about a month of quiet. It also made the diagnosis feel settled: more logs, not enough disk.&lt;/p&gt;
&lt;p&gt;Then the alert came back. And came back sooner.&lt;/p&gt;
&lt;p&gt;This time I opened a shell in the pod and compared two numbers:&lt;/p&gt;</description></item><item><title>Set up a Kubernetes cluster with MetalLB</title><link>https://blog.thalamus.am/posts/setup-kubernetes-cluster-with-metallb/</link><pubDate>Sat, 29 Apr 2023 00:00:00 +0000</pubDate><guid>https://blog.thalamus.am/posts/setup-kubernetes-cluster-with-metallb/</guid><description>&lt;img src="https://blog.thalamus.am/posts/setup-kubernetes-cluster-with-metallb/editorial-cover.png" alt="Featured image of post Set up a Kubernetes cluster with MetalLB" /&gt;&lt;p&gt;A Kubernetes cluster on your own VMs needs a way to give services an address that other machines can reach. This lab uses kubeadm to build the cluster, Calico for pod networking, and MetalLB for &lt;code&gt;LoadBalancer&lt;/code&gt; services.&lt;/p&gt;
&lt;p&gt;The setup had three Ubuntu VMs: one control plane node and two workers. These notes keep the 2023 versions, including Kubernetes &lt;code&gt;1.26.4&lt;/code&gt; and Calico &lt;code&gt;3.25.1&lt;/code&gt;. Some steps were missing from the first version, especially the MetalLB network configuration. I explain those gaps below, but the complete setup still needs a fresh test.&lt;/p&gt;</description></item><item><title>Deploy a microservices demo with Rancher</title><link>https://blog.thalamus.am/posts/creating-microservices-deployments/</link><pubDate>Sat, 09 May 2020 00:00:00 +0000</pubDate><guid>https://blog.thalamus.am/posts/creating-microservices-deployments/</guid><description>&lt;img src="https://blog.thalamus.am/posts/creating-microservices-deployments/editorial-cover.png" alt="Featured image of post Deploy a microservices demo with Rancher" /&gt;&lt;p&gt;This lab follows a microservices demo from three Ubuntu machines to an application deployed on Kubernetes. Rancher provides the interface for creating the cluster and registering its nodes.&lt;/p&gt;
&lt;p&gt;The notes and screenshots come from my 2020 demo. The package repositories and Rancher screens have changed since then. The sequence is still useful to read, but it needs a fresh lab run before it can serve as a current tutorial.&lt;/p&gt;
&lt;h2 id="the-three-nodes-have-different-jobs"&gt;The three nodes have different jobs
&lt;/h2&gt;&lt;p&gt;The original cluster assigned these roles:&lt;/p&gt;</description></item><item><title>CI/CD for a Java project: manual installation</title><link>https://blog.thalamus.am/posts/ci-cd-for-java-project-manual-installation/</link><pubDate>Sun, 12 Apr 2020 00:00:00 +0000</pubDate><guid>https://blog.thalamus.am/posts/ci-cd-for-java-project-manual-installation/</guid><description>&lt;img src="https://blog.thalamus.am/posts/ci-cd-for-java-project-manual-installation/editorial-cover.png" alt="Featured image of post CI/CD for a Java project: manual installation" /&gt;&lt;p&gt;In this Java CI/CD lab, Jenkins runs the build jobs, Docker builds container images, and Nexus stores them. Nginx gives Jenkins and Nexus their own HTTPS addresses. Before connecting the pipeline, each service needs to work on its own.&lt;/p&gt;
&lt;p&gt;I split the original project into two parts: install the components by hand first, then automate the setup with Terraform and Ansible. This page covers the manual installation recorded in 2020. It stops before the Java build job and Kubernetes deployment.&lt;/p&gt;</description></item></channel></rss>