Kubernetes cluster

Why Kubernetes

I have been hosting my own services for a few years now. Starting on a Debian server, I moved to Docker containers quickly due to the ease of managing them, installing applications and removing them completely. For some time, I have been looking into the benefits of Kubernetes over Docker (or similar solutions). Most of all, possibilities like GitOps and multi-device setups made me curious. I decided to give it a try and migrate my personal hosting projects to Kubernetes.

Repository structure

In order to use this git repository as single source of truth and using infrastructure as code (IaC), Flux is used as a tool.

This repository is structured following the recommendation of Flux. For every deployed application, there is a standard configuration in the base directory. In the corresponding README.md-files, I try to reason my decision for the tool choice and show tool-specific insights (e.g. troubleshooting). Environment-specific configuration (e.g. ip addresses, version numbers, etc.) are outsourced in the environment directory using so called Kustomization Overlays. Applications, which are not referenced in one environment, are not deployed there. See the template to derive your own configuration as fast as possible.

Getting started

In order to bootstrap the cluster, follow the steps here.

Troubleshooting

• To get a lead on the current issues, use this command and add the corresponding namespace: watch kubectl get events -n <namespace> --field-selector type=Warning --sort-by='.lastTimestamp'