Kill SSH, Keep Kubernetes: Deploying Talos Linux on High-Performance VDS in Norway

If you are still SSH-ing into your Kubernetes nodes to run apt-get upgrade, you are doing it wrong. I said it. It’s 2025. Treating your infrastructure like a collection of fragile pets that need constant grooming is a fast track to burnout and security breaches.

We've all been there. A kernel patch goes sideways on a Friday night. A random dependency update breaks the kubelet. Or worse, someone left an SSH key on a node that they shouldn't have. The traditional Linux distribution—Ubuntu, Debian, CentOS—was never designed to be a single-purpose container host. It carries 30 years of baggage you don't need.

Enter Talos Linux. No SSH. No console. Read-only file system. It’s not just a stripped-down distro; it’s a paradigm shift. And when you pair it with the raw NVMe performance of CoolVDS in our Oslo datacenter, you get a Kubernetes cluster that is virtually indestructible and compliant with the strictest Norwegian security standards.

The Architecture of Immutability

Talos is Linux designed for Kubernetes. It excludes everything that isn't necessary to run K8s. There is no bash, no GNU utilities, and absolutely no SSH. The entire OS is managed via a gRPC API. This aligns perfectly with the GitOps philosophy.

Why does this matter for a VPS in Norway? Performance and Security.

When you strip away the bloat, you reduce the attack surface by 90%. There is no shell to exploit. From a compliance perspective—think Datatilsynet and GDPR—running an immutable OS means you can mathematically prove the state of your infrastructure at any given moment. There is no configuration drift.

Pro Tip: Because Talos is API-driven, latency to the control plane is critical. Running your control plane on CoolVDS in Oslo ensures single-digit millisecond latency for etcd replication across the Nordic region. High latency kills etcd stability.

Prerequisites and Hardware

Talos is lightweight, but Kubernetes is not. You need fast I/O. etcd is notoriously sensitive to disk write latency. If your fsync takes too long, your cluster leader elections will fail.

We use CoolVDS instances because they expose KVM virtualization with direct NVMe pass-through. Don't waste your time trying to run Talos on budget containers that steal CPU cycles.

• Control Plane: 2 vCPU, 4GB RAM, 50GB NVMe (Minimum)
• Worker Node: 4 vCPU, 8GB RAM, 100GB NVMe
• Network: Private networking enabled (for secure API traffic)

Step 1: The Configuration Strategy

You manage Talos using talosctl. First, we need to generate a machine configuration. Since we are targeting July 2025 standards, we are looking at Talos v1.9.x and Kubernetes v1.32.

# Install talosctl (Linux/macOS)
curl -sL https://talos.dev/install | bash

# Define your cluster endpoint (The Public IP of your CoolVDS Control Plane)
export CLUSTER_NAME="coolvds-oslo-01"
export CONTROL_PLANE_IP="185.xxx.xxx.xxx"

# Generate configuration files
talosctl gen config $CLUSTER_NAME https://$CONTROL_PLANE_IP:6443

This command outputs three critical files: controlplane.yaml, worker.yaml, and talosconfig. Keep talosconfig safe; it is your root key to the cluster.

Step 2: Booting Talos on CoolVDS

On CoolVDS, you can mount the Talos ISO directly. Once the instance boots from the ISO, it enters maintenance mode, waiting for a config. It doesn't install itself automatically—it waits for the API call. This is security by default.

Identify the IP address of your new instance. Let's say your first node is at 185.10.10.10. You apply the configuration remotely from your workstation.

# Apply the control plane configuration to the first node
talosctl apply-config --insecure \
  --nodes 185.10.10.10 \
  --file controlplane.yaml

Note: We use --insecure here only for the initial bootstrap because the node doesn't have its certificates yet. Once bootstrapped, all communication is mutually TLS authenticated.

Defining the Installation Disk

Before applying, you might need to patch the controlplane.yaml to ensure it targets the correct NVMe drive on CoolVDS. By default, Talos tries to be smart, but explicit is better than implicit.

machine:
  install:
    disk: /dev/vda # Standard KVM VirtIO block device
    image: factory.talos.dev/installer/ce4c98...:v1.9.1
    wipe: true
  network:
    hostname: oslo-cp-01

Step 3: Bootstrapping the Cluster

Once the config is applied, the node will reboot and install Talos to the disk. Wait for it to come back online. Now, we tell the cluster to form.

# Configure local talosctl to talk to the new node
talosctl config endpoint $CONTROL_PLANE_IP
talosctl config node $CONTROL_PLANE_IP

# Bootstrap etcd
talosctl bootstrap

This command initializes etcd. Do this only once. If you run this on a running cluster, you will have a very bad day.

Step 4: Verifying the State

After a few minutes, your node should be ready. Retrieve the standard kubeconfig to use with kubectl.

talosctl kubeconfig .
kubectl --kubeconfig=kubeconfig get nodes

You should see:

NAME          STATUS   ROLES           AGE     VERSION
oslo-cp-01    Ready    control-plane   2m15s   v1.32.0

Handling Storage and Networking

A raw Kubernetes cluster needs a CNI (Container Network Interface). Talos ships with Flannel by default, but for high-performance setups on CoolVDS, we often swap to Cilium for eBPF capabilities. To disable the default CNI during config generation:

talosctl gen config $CLUSTER_NAME https://$CONTROL_PLANE_IP:6443 --config-patch '[{"op": "add", "path": "/cluster/network/cni", "value": {"name": "none"}}]'

Then install Cilium via Helm after bootstrap. This gives you deep visibility into packet flows—essential when debugging microservices latency.

Why This Architecture Wins

For businesses in Norway, data sovereignty is non-negotiable. By running Talos on CoolVDS, you ensure that not only is the data physically located in Oslo, but the operating system itself is hardened against the most common vectors of data exfiltration. No one can SSH in and copy your database file if there is no SSH daemon running.

Final Thoughts

Kubernetes is complex enough without having to manage the OS underneath it. Talos removes that layer of complexity entirely. It forces you into best practices. It makes your infrastructure disposable and reproducible.

But software is only half the equation. Talos requires fast hardware to perform its API magic and maintain etcd quorum health. That’s where we come in.

Ready to build a cluster that actually sleeps at night? Spin up a CoolVDS NVMe instance and flash the Talos ISO today.