Thanks to visit codestin.com
Credit goes to github.com

Skip to content
/ k8s Public

My personal Kubernetes environment running Talos/Omni and managed by Terraform/ArgoCD

kenlasko/k8s

Repository files navigation

Introduction

This is the Git repository that contains all the configuration for my multiple homelab Kubernetes clusters. The clusters are used to host a number of self-hosted services mostly focused on movies and TV along with all the supporting software. This repository is fully gitops-optimized and is managed by ArgoCD.

The clusters are built on Sidero Lab's Talos OS using on-prem Omni for low-level cluster management.

Cluster Descriptions

Home Cluster

This is my primary cluster which is used to self-host numerous applications, from the *arr stack and its supporting apps/tools to Home Assistant to replacements for cloud-services such as Nextcloud.

My home cluster runs on 7 mini-PCs named NUC1 through to NUC7. NUC1-NUC3 are used as control-plane nodes, while NUC4-NUC7 are workers. While this repo can be used for any environment, some workloads require (or benefit from) hardware that is specific to certain named nodes. The manifests are configured for this. For example:

  • Plex works best on nodes with Intel GPUs for efficient transcoding. NUC5 and NUC6 have the N100 processor, which is best for transcoding, but can run on NUC4 or NUC7 which run the older N95 if necessary.
  • My Home Assistant appstack requires access to USB-attached resources such as Zigbee/Z-Wave controllers and a UPS monitor. Obviously, these are plugged into one node, which the pods require access to (currently NUC4).
  • PostgreSQL requires local storage, which is available on NUC4-NUC7.
  • Longhorn is configured to only run on NUC4-NUC7 in order to keep workloads off the control-plane nodes

Server Specs

Name Make/Model CPU RAM Disk Purpose
NUC1 Intel NUC6CAYH Intel Celeron J3455 (2M Cache, up to 2.30 GHz) 8 GB DDR3L-1600/1866 500 GB SSD Control Plane
NUC2 Intel NUC6CAYH Intel Celeron J3455 (2M Cache, up to 2.30 GHz) 8 GB DDR3L-1600/1866 500 GB SSD Control Plane
NUC3 Intel NUC5CPYH Intel Celeron N3060 (2M Cache, up to 2.48 GHz) 8 GB DDR3L-1333/1600 500 GB SSD Control Plane
NUC4 Beelink U59 Pro Intel Celeron N5105 (4M Cache, up to 2.90 GHz) 16 GB DDR4-2400 500 GB M.2 SSD Worker
NUC5 Beelink Mini S12 Pro Intel N100 (6M Cache, up to 3.40 GHz) 16 GB DDR4-3400 500 GB M.2 SSD Worker
NUC6 Beelink Mini S12 Pro Intel N100 (6M Cache, up to 3.40 GHz) 16 GB DDR4-3400 500 GB M.2 SSD Worker
NUC7 Beelink U59 Pro Intel Celeron N5105 (4M Cache, up to 2.90 GHz) 16 GB DDR4-2400 500 GB M.2 SSD Worker

Cloud Cluster

This cluster is hosted on a single node in Oracle Cloud and is used as a disaster-recovery solution for my home cluster. It replicates the function of some critical services:

  • PostgreSQL
  • AdGuard Home
  • VaultWarden
  • UCDialplans website

The PostgreSQL servers are live replicas of the home-based servers. Most of the services are in warm-standby mode. AdGuard Home is the only actively used service for when I am away from home as it responds to requests from *.dns.ucdialplans.com. However, it is very lightly used, since my phone is usually connected to my home network via Wireguard.

The Oracle Cloud Talos OS image is not available on Oracle Cloud but can be built by following these procedures.

Lab Cluster

This is my Kubernetes lab environment, which I have historically used to test out new features before deploying to my 'production' Kubernetes cluster. It runs on 1 to 3 Talos VMs as needed on my Windows 11 machine under Hyper-V. It is not typically in use.

Remote Access

Most services are only accessed by myself and are only available via my local network or my Unifi-hosted Wireguard VPN. Services that are publically available such as UCDialplans.com or Overseerr (for my family) are published via my dedicated cloud-based Pangolin instance.

Inter-Cluster Communication

I use the Tailscale Operator to securely share data between my home and cloud cluster. I decided to use limited service-level links instead of a cluster-wide link to limit exposure. This does complicate things somewhat, but is generally manageable.

Folder structure

The folders are laid out in the following manner:

  • argocd: the "brains" of the operation that controls the creation/management of all resources
  • argocd-appsets: where all the ArgoCD ApplicationSet definitions reside. An ApplicationSet automates the creation of ArgoCD Application definitions, which tells ArgoCD where to find the relevant manifests for each application. Broken down by type (app, database, system etc). The ArgoCD applications reference manifests stored in the manifests folder.
  • docs: documents
  • manifests: all the manifests used by each application. Broken down by type (app, database, system etc) then by name. Used by ArgoCD applications.
  • helm: where I keep my universal Helm chart for most non-Helm based applications
  • scripts: a mish-mash of scripts used for various purposes

Applications are structured for Kustomize by following this structure underneath manifests:

appName/
├── base/
│   ├── kustomization.yaml    # Base manifests and Helm chart setup
│   ├── deployment.yaml       # Base Deployment manifest
│   ├── service.yaml          # Base Service manifest
│   └── values.yaml           # Base Helm values (if using Helm chart)
├── overlays/
│   ├── cloud/
│   │   ├── kustomization.yaml  # Patches and config specific to Cloud cluster
│   │   ├── patch.yaml          # Example patch (e.g., change replicas)
│   │   └── values.yaml         # Helm values patch (if using Helm chart)
│   ├── home/
│   │   ├── kustomization.yaml  # Patches and config specific to Home cluster
│   │   ├── patch.yaml          # Example patch (e.g., change replicas)
│   │   └── values.yaml         # Helm values patch (if using Helm chart)
│   ├── lab/
│   │   ├── kustomization.yaml  # Patches and config specific to Lab cluster
│   │   ├── patch.yaml          # Example patch (e.g., change replicas)
│   │   └── values.yaml         # Helm values patch (if using Helm chart)

Software Updates

All software updates are managed via Renovate. Renovate watches the Github repo and checks for software version updates on any Helm chart, ArgoCD application manifest or deployment manifest. If an update is found, Renovate will update the version in the repo and let ArgoCD handle the actual upgrade. All updates are logged in the repo as commits.

The configuration for Renovate is stored in renovate.json. The dashboard is available at https://developer.mend.io/github/kenlasko

Renovate is set to automatically and silently upgrade every software package EXCEPT for the following:

When upgrades for the above packages are found, Renovate will create a pull request that has to be manually approved (or denied). Once approved, ArgoCD manages the actual upgrade as with any other software.

Cluster Installation Procedures

This document outlines the steps to install the cluster using SideroLabs Omni, a bootstrap script and ArgoCD.

Commit Pre-Check

This repository makes use of pre-commit to guard against accidental secret commits. When you attempt a commit, Pre-Commit will check for secrets and block the commit if one is found. It is currently using GitGuardian ggshield for secret validation. Requires a GitGuardian account, which does offer a free tier for home use. See this document for more information.

Useful Commands

Check for open port without tools

Many container images do not have any tools like nc to check network port connectivity. This handy command will allow you to do that with just echo

(echo > /dev/tcp/<servicename>/<port>) >/dev/null 2>&1 && echo "It's up" || echo "It's down"

Validate Kustomize manifests

kustomize build ~/k8s/manifests/apps/adguard/overlays/home/ --enable-helm --load-restrictor LoadRestrictionsNone > ~/test-kustomize.yaml

Validate Homegrown Helm Chart

helm template plex ~/k8s/helm/baseline -n media-apps -f ~/k8s/manifests/media-apps/plex/values.yaml > ~/helm-test.yaml

Generate Kustomize Manifest and Apply to Kubernetes

kustomize build k8s/manifests/apps/adguard/overlays/home/ --enable-helm --load-restrictor LoadRestrictionsNone | kubectl apply -f -

Related Repositories

Links to my other repositories mentioned or used in this repo:

  • NetbootXYZ: Simplified PXE boot setup for Omni-managed Talos nodes.
  • NixOS: A declarative OS modified to support my Kubernetes cluster
  • Omni: Creates and manages the Kubernetes clusters.

About

My personal Kubernetes environment running Talos/Omni and managed by Terraform/ArgoCD

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Contributors 2

  •  
  •