TJs-Kubernetes-Service

TJ’s Kubernetes Service

• Summary
• Requirements
• Instructions
• Configuration Options
  • Storing State in HCP Terraform
  • Using a Different CNI
  • Using a Cloud Controller Manager
  • Exposing Control Plane Metrics
  • Adding a GPU Worker
• Managing the Cluster
• Documentation

---

Summary

TJ’s Kubernetes Service, or TKS, is a collection of Terraform configurations that deploy Talos Linux Kubernetes clusters to Proxmox VE, using the BPG Proxmox and Sidero Labs Talos providers.

---

Requirements

Requirement	Description
terraform	Creates and manages the cluster. Version 1.16 or newer
kubectl	Used by tks
talosctl	Used by tks
openssl	Used by tks to check kubelet certificate requests before approving them
Proxmox VE	A host or cluster to run the nodes on
IOMMU	Only for a GPU worker. Enabled on the host, with each GPU alone in its IOMMU group

---

Instructions

1. If you don’t already have one, create a Proxmox API token for the Terraform provider to use. The bootstrap Terraform root can be used to create the users listed in vars/bootstrap.tfvars, each of which comes with its own role and token.

   The example file defines a user with only the privileges TKS needs (listed in the Security guide), plus users for the Proxmox CSI Plugin and the Proxmox Cloud Controller Manager.

   The bootstrap root needs root credentials, so export them in a separate shell used only for this step:

   # The provider prefers a token over a password, so ensure it won't interfere if it's set
   unset PROXMOX_VE_API_TOKEN 
   
   export PROXMOX_VE_ENDPOINT="https://earth.sol.milkyway:8006"
   export PROXMOX_VE_INSECURE="true"
   export PROXMOX_VE_USERNAME="root@pam"
   export PROXMOX_VE_PASSWORD="REPLACEME"
   
   cd bootstrap
   terraform init
   terraform apply -var-file=../vars/bootstrap.tfvars
   cd ..
   ./bin/tks token tks@pve
   

   tks token prints a user’s token as <id>=<secret>, the form PROXMOX_VE_API_TOKEN takes.

2. Copy vars/config.env.example to vars/config.env, configure it, and source it as per the provider’s documentation.

   source vars/config.env
   

3. Create a tfvars file for the cluster. Every input is described in Configuration, and vars/test.tfvars is a complete example. Nodes are a map keyed by hostname, each with a static IP and VMID.

4. Initialize Terraform and create a workspace for the cluster.

   terraform init
   terraform workspace new tks-test
   

5. Create the cluster:

   terraform apply --var-file="vars/test.tfvars"
   

6. Merge the Talos and Kubernetes configuration files into ~/.talos/config and ~/.kube/config. Other clusters’ entries are kept, entries from an earlier build of the same cluster are replaced, and the new cluster becomes the current context.

   ./bin/tks config
   

7. Confirm that Kubernetes is bootstrapped and that every node has joined. The control plane can take a moment to respond. Each node’s status is also visible through talosctl or the VM console in Proxmox.

   watch kubectl get nodes,all -A
   

8. Kubelet serving certificates require their certificate signing requests (CSRs) to be approved. Without an approver such as Kubelet CSR Approver, approve them with tks. It only approves a CSR that comes from a node and names nothing but that node’s hostname and IP.

   ./bin/tks approve-csrs
   

9. Check the cluster’s health. tks doctor checks the Proxmox API, each VM, each node’s Talos and Kubernetes versions against the tfvars, etcd membership, GPU drivers, and talosctl health.

   ./bin/tks doctor
   

---

Configuration Options

Storing State in HCP Terraform

Both Terraform roots store state locally by default. State holds the cluster’s secrets and, for the bootstrap root, the Proxmox API tokens; the Security guide covers keeping it safe. To store it in HCP Terraform instead, complete these steps before the first terraform init in each root:

1. In the HCP Terraform organization, set the Default Execution Mode to Local under Settings > General, so plans run locally where Proxmox is reachable.
2. Run terraform login.
3. Copy cloud_override.tf.example to cloud_override.tf, and bootstrap/cloud_override.tf.example to bootstrap/cloud_override.tf, and set the organization in both.

The bootstrap root uses a workspace named tks-bootstrap. Cluster workspaces are tagged tks-cluster, and HCP Terraform uses each workspace’s name as is, so a tks- prefix is recommended. The first terraform init in the repository root prompts for a workspace name, because no workspace has the tag yet; enter the cluster’s workspace name there instead of running terraform workspace new. If a root already has local state, terraform init offers to migrate it.

Using a Different CNI

Talos uses Flannel by default. To use a different CNI, set cluster.disable_flannel to true when the cluster is created. The cluster is not functional, and nodes cannot be upgraded, until a CNI is installed.

Using a Cloud Controller Manager

Set cluster.external_cloud_provider to true to hand node initialization and cleanup to a cloud controller manager such as the Proxmox CCM. It sets each node’s providerID and its topology.kubernetes.io/zone and region labels, and deletes a node from Kubernetes once its VM is gone. The CCM is deployed separately; an example deployment, including where it fits in a cluster’s bootstrap order, is available in Kubernetes-Manifests. Its Proxmox user is defined in vars/bootstrap.tfvars.

New nodes join with the node.cloudprovider.kubernetes.io/uninitialized taint and keep it until the CCM initializes them. Flannel, CoreDNS and kube-proxy tolerate the taint, but other workloads do not schedule, so install the CCM first.

Enable it when the cluster is created where possible. Nodes that joined before it was enabled are ignored by the CCM until they register again; see tks reregister under Managing the Cluster.

Exposing Control Plane Metrics

Talos binds the metrics endpoints for etcd, the scheduler, the controller-manager and kube-proxy to localhost, so a monitoring stack such as kube-prometheus-stack cannot scrape them. Set cluster.expose_metrics to true to bind them to the node addresses instead. The scheduler and controller-manager still authenticate scrapes with TLS and RBAC, but the etcd (2381) and kube-proxy (10249) listeners are plain HTTP and readable from the node network, which is why this is opt-in.

On a running cluster, the scheduler, controller-manager and API server apply the change on their own. etcd does not, because Talos refuses API-driven etcd restarts: reboot the control plane nodes with tks reboot, naming each of them. It restarts them one at a time and waits for etcd before moving to the next. kube-proxy is a bootstrap manifest and only re-renders on talosctl upgrade-k8s --to $CURRENT_VERSION.

Adding a GPU Worker

Set gpu_workers to add worker nodes that each have a GPU from the Proxmox host passed through. Each node names its GPU by the PCI address lspci shows for it, so identical cards are told apart:

gpu_workers = {
  nodes = {
    "k8s-node-gpu-1" = { ip = "192.168.40.31", vm_id = 4031, cores = 16, memory_mb = 196608, pci_address = "05:00.0" }
    "k8s-node-gpu-2" = { ip = "192.168.40.32", vm_id = 4032, cores = 16, memory_mb = 196608, pci_address = "06:00.0" }
  }
}

TKS reads the rest of what it needs about each card from the Proxmox API, and creates a PCI resource mapping named <cluster>-gpu-<vmid> that holds only that card. The plan fails if nothing is at an address, if a card has no IOMMU group, or if two nodes name the same card. If a card moves to another slot, set its new address and apply again. GPU nodes are built from their own Talos image with the siderolabs/amdgpu extension.

GPU nodes carry the amd.com/gpu:NoSchedule taint and the tks.io/pool=gpu label. Every TKS cluster enables the ExtendedResourceToleration admission plugin, so pods that request amd.com/gpu get the matching toleration without declaring it. Anything else that should run on a GPU node needs its own toleration, including the AMD device plugin that advertises amd.com/gpu to Kubernetes, which is deployed separately.

Proxmox starts only one VM per card, so two clusters on the same host cannot run GPU nodes with the same card at once.

---

Managing the Cluster

Scaling and upgrades are driven by the tfvars file. Add, remove or resize nodes, or change talos_version or kubernetes_version, then run terraform plan and apply. Upgrades happen in place, one node at a time with control planes first; nodes are drained before a Talos upgrade, and Kubernetes upgrades are health checked. Renovate opens pull requests for new versions and checks that the Talos and Kubernetes versions are compatible. talos_config_version stays at the version the cluster was created with, as described in step 3 of the Instructions.

Some operations need more than an apply. bin/tks handles them from the repository root in the cluster’s workspace. doctor and reboot also call the Proxmox API, so they need PROXMOX_VE_ENDPOINT and PROXMOX_VE_API_TOKEN exported, as vars/config.env does. It acts on the cluster of the selected Terraform workspace, using the configuration files in that workspace’s outputs, not the current kubectl or talosctl context:

Command	Use
config	Merges the cluster’s Talos and Kubernetes configuration files into ~/.talos/config and ~/.kube/config, replacing entries from an earlier build of the same cluster
approve-csrs	Approves pending kubelet serving certificate requests that come from a node and name only its own hostname and IP. Needed without an approver in the cluster, after nodes are added and when their certificates rotate
doctor	Checks the Proxmox API, the VMs, the nodes’ Talos and Kubernetes versions against the tfvars, etcd membership, GPU drivers and talosctl health, without changing anything
token USER	Prints a user’s API token from the bootstrap root as <id>=<secret>
remove NODE	Takes a node out of the cluster: drains it, removes it from etcd if it is a control plane, resets it and deletes it from Kubernetes. Run it before removing the node from the tfvars. If it runs afterwards, it removes the dead etcd member instead, which requires at least three control planes. It refuses to remove the last control plane. With a cloud controller manager, workers can be removed with only the apply, but draining first is still recommended
reboot [NODE...]	Restarts nodes through Proxmox after a change to cores, memory or PCI devices, which Terraform does not apply to running VMs. Each node is drained, restarted, and waited on before the next
reregister [NODE...]	Registers nodes again after cluster.external_cloud_provider is enabled on an existing cluster. Each node is drained, deleted from Kubernetes with its remaining pods, rebooted onto its new pod network, and waited on until the CCM has initialized it. Needed once per cluster

Without node names, reboot and reregister process every node, control planes first.

./bin/tks remove k8s-node-3
./bin/tks reboot
./bin/tks reregister k8s-node-2 k8s-node-3
./bin/tks token kubernetes-ccm@pve

---

Documentation

More detailed documentation can be found in the docs directory:

Document	Description
Configuration	Every input variable, generated from the code
Architecture	What TKS creates and how it fits together
Security	Credentials, secrets in Terraform state, and scanning
CI/CD	Checks, releases, and dependency updates
Decisions	Architectural decision records explaining why TKS is built the way it is
Contributing	How to propose a change