Cloud Setup
I operate multiple Kubernetes clusters across cloud and on-prem environments, deliberately segmented by trust level, network exposure, and failure tolerance. These clusters host production-facing services, observability backends, CI/CD infrastructure, and disposable scraping workloads.
SM Cluster
Aespa nodepool
I started my self-hosted Kubernetes journey with this nodepool, setting up a single control plane and three workers to create a highly available foundation for my core workloads.
| name | role | vCPU | RAM (GB) | Storage |
|---|---|---|---|---|
| Karina | control plane | 6 | 12 | 200GB |
| Giselle | worker | 8 | 24 | 1.2TB |
| Ningning | worker | 8 | 24 | 1.2TB |
| Winter | worker | 8 | 24 | 1.2TB |
Red Velvet nodepool
As the cluster grew and I needed more capacity, I added this nodepool, expanding the control plane to three nodes and adding three more workers.
| name | role | vCPU | RAM (GB) | Storage |
|---|---|---|---|---|
| Irene | control plane | 6 | 12 | 200GB |
| Seulgi | worker (was control plane) | 4 | 6 | 400GB |
| Wendy | worker | 12 | 48 | 1.6TB |
| Joy | worker | 6 | 16 | 400GB |
| Yeri | worker | 6 | 16 | 400GB |
Hearts2Hearts nodepool
By early 2025, the cluster's demands had grown - particularly on the control plane. API server load was increasing, especially during deploy-heavy periods and when running resource-intensive workloads like Prometheus or ArgoCD. To keep things responsive and maintain headroom, I brought in a third node pool with beefier control-plane nodes and additional workers.
This also allowed me to spread the control plane across all three node pools, improving availability and reducing the blast radius of any single failure domain.
| name | role | vCPU | RAM (GB) | Storage |
|---|---|---|---|---|
| Jiwoo | control plane | 6 | 12 | 400GB |
| Stella | worker | 6 | 12 | 400GB |
| Ian | worker | 6 | 12 | 400GB |
| Yuha | worker | 4 | 6 | 400GB |
| Yeon | worker | 4 | 6 | 400GB |
| Juun | worker | 6 | 12 | 200GB |
Viviz cluster
This is another Kubernetes cluster set up with Talos Linux. It handles all http requests from the "outside world" (including this website!)- no critical data is stored on these nodes. These nodes are rented from Hivelocity.
members
| name | role | vCPU | RAM (GB) | Storage |
|---|---|---|---|---|
| Umji | control plane | 2 | 4 | 80 GB |
| Eunha | worker | 2 | 4 | 80 GB |
| Sinb | worker | 12 | 24 | 640 GB |
Brown Eyed Girls cluster
I also have a few miscellaneous VPSes that I am renting from multiple providers throughout the EU and Asia. These nodes are responsible for workloads designed to tolerate node termination and avoid coupling to a single provider or identity.
members
| name | vCPU | RAM (GB) | Storage |
|---|---|---|---|
| Miryo | 4 | 8 | 100 GB |
| Narsha | 4 | 8 | 100 GB |
| JeA | 12 | 32 | 200 GB |
| Gain | 12 | 32 | 200 GB |
Soloists
I maintain one bootstrap node, running docker in swarm mode, that provdes Talos configuration and DNS information for custom domains. As a single point of failure, it's on my list for finding an alternative implementation, but it's utilised so infrequently it'll be rare that an issue occurs.
members
- Ailee (1vCPU/2GB RAM) rented from DeinServerHost