Resisting impulses is hard. We all have such impulses: like mindlessly scrolling social media in the morning, eating junk food, or too many coffee-breaks at work. They can be manifold, but they are so enticing in the moment, because they temptate us with immediate pleasure or stress release. It’s when our primitive, short-term thinking mind tries to get control. In the book “Thinking Fast and Slow”, Daniel Kahneman describes two modes of thinking:
Inspired by Jen Vermet’s ship-it and weekly letters, I will start to share my thoughts and learnings in public. I love how personal and introspective her thoughts and shared experiences are. I’ve started journaling last year, but my thoughts are mostly very raw and hidden to the outside world. By starting a public journal, I want to challenge myself to become more open and overcome the imposter that my thoughts are not worth being shared.
Recently, I tried to configure calico networking on a self-managed Kubernetes cluster on Azure. It did not work out of the box and many instructions on the internet did not work for me. In the following, I want to share my setup. To set up the network and VMs, I followed this tutorial. After installing the default configuration of calico, inter-node communication between pods did not work. My working approach uses User-Defined-Routes (UDR) on Azure to route traffic from the different pod-subnets of each node.
In this tutorial, I want to show you how to bootstrap a Kubernetes cluster with kubeadm using your customized Kubernetes fork. This might be useful if you want to use new features that are not yet merged in the upstream. For development, it’s of course much easier to set up a local cluster (./hack/local-up-cluster.sh), but to test functionality across different nodes, you might need a distributed cluster. One option is to install it The hard way, but I think it’s more convenient to use kubeadm.
This is an extensive tutorial on how to set up a Kubernetes cluster that supports pod migration. Why Statelessness is the basic foundation for microservices run inside Kubernetes. Outside it’s main application domain, the platform also appeals to the High Performance Computing (HPC) community for that infrastructure management can be delegated to cloud providers and it’s on-demand scaling. The challenge is that HPC jobs are usually long running and stateful. Jobs such as simulations or optimization problems usually keep their state in memory and state checkpointing on disk is not always available.
InfluxDB is an Open-Source timeseries database which can be used for monitoring Kubernetes clusters. In this tutorial, I want to show you step by step how to get a dashboard with metrics on Kuberntes resource usage of podes and nodes. It’s not difficult, but the official documentation is outdated and confusing, so I hope to make it easier for you. We will use InfluxDB2 which includes a nice dashboard and supports the Flux QL query language.