DEV Community: Luger Lex Pit-og

[Lab Notes] Kubernetes the Hard Way, For Real This Time (Step 08)

Luger Lex Pit-og — Wed, 23 Sep 2026 20:47:21 +0000

Continuing my Kubernetes the Hard Way homelab build. Steps 01-07 are already done, this covers step 08.

Original guide: 08-bootstrapping-kubernetes-controllers.md

Thoughts I had while doing this

Much like the previous step with etcd, this one is about installing more components. Mainly the Kubernetes API Server, Scheduler, and Controller Manager.

Same pattern as before: copy the binaries over to the controller node, configure them, and each one becomes a running Linux service.

What I was trying to figure out was what each of these components is for. I already get etcd, it stores the state. Here's my attempt at explaining the other three:

API Server - this is where every API call from the other Kubernetes components ends up. If you want to do anything in the cluster, it has to go through here, since it's the only component that reads/writes directly to etcd. That's also why it's loaded with security config (ca.crt, ca.key, etc.). It's the gatekeeper in front of the database.
Scheduler - decides which node a pod should run on. It just checks whether a pod already has an assigned node; if not, it calls the API server to assign one. The API server is the one that actually writes that update to etcd, the scheduler just makes the decision and reports it.
Controller Manager - as far as I understand it, this is really just a bundle of other controllers. If the API server is the one directly reading/writing etcd, and the scheduler just decides pod placement, the controller manager is just "everything else." A couple examples of what that covers:
- "One of the physical servers running our pods went down, let me do something about it."
- "A job failed inside a pod, let me retry it."

A gotcha along the way: apiserver wouldn't start

Hit a wall trying to get kube-apiserver up:

root@server:~# systemctl is-active kube-apiserver
activating
root@server:~# systemctl status kube-apiserver
● kube-apiserver.service - Kubernetes API Server
     Loaded: loaded (/etc/systemd/system/kube-apiserver.service; enabled; vendor preset: enabled)
     Active: activating (auto-restart) (Result: exit-code) since Thu 2026-09-17 13:13:42 UTC; 89ms ago
       Docs: https://github.com/kubernetes/kubernetes
    Process: 56537 ExecStart=/usr/local/bin/kube-apiserver --allow-privileged=true ... (code=exited, status=1/FAILURE)
   Main PID: 56537 (code=exited, status=1/FAILURE)
        CPU: 48ms

Sep 17 13:13:42 server systemd[1]: kube-apiserver.service: Main process exited, code=exited, status=1/FAILURE
Sep 17 13:13:42 server systemd[1]: kube-apiserver.service: Failed with result 'exit-code'.

Checked the logs for the actual error:

root@server:~# journalctl -u kube-apiserver
...
Sep 17 13:08:07 server kube-apiserver[55147]: I0917 13:08:07.493634   55147 server.go:147] Version: v1.32.3
Sep 17 13:08:07 server kube-apiserver[55147]: E0917 13:08:07.493805   55147 run.go:72] "command failed" err="failed to create listener: failed to listen on 0.0.0.0:6443: listen tcp 0.0.0.0:6443: bind: address already in use"
Sep 17 13:08:07 server systemd[1]: kube-apiserver.service: Main process exited, code=exited, status=1/FAILURE
Sep 17 13:08:07 server systemd[1]: kube-apiserver.service: Failed with result 'exit-code'.
Sep 17 13:08:12 server systemd[1]: kube-apiserver.service: Scheduled restart job, restart counter is at 1.
...

Something else was already bound to port 6443:

root@server:~# sudo ss -tlnp | grep 6443
LISTEN 0      4096               *:6443             *:*    users:(("k3s-server",pid=623,fd=13))

Turned out I'd tried setting up k3s on this same machine a few months back and forgot about it. Stopped and disabled the leftover service:

root@server:~# sudo systemctl stop k3s
sudo systemctl disable k3s
Removed /etc/systemd/system/multi-user.target.wants/k3s.service.

After that, kube-apiserver started cleanly:

root@server:~# systemctl is-active kube-apiserver
active
root@server:~# kubectl cluster-info \
  --kubeconfig admin.kubeconfig
Kubernetes control plane is running at https://127.0.0.1:6443

Now here's the actual step.

Prerequisites

root@luger-VirtualBox:~/kubernetes-the-hard-way# scp \
  downloads/controller/kube-apiserver \
  downloads/controller/kube-controller-manager \
  downloads/controller/kube-scheduler \
  downloads/client/kubectl \
  units/kube-apiserver.service \
  units/kube-controller-manager.service \
  units/kube-scheduler.service \
  configs/kube-scheduler.yaml \
  configs/kube-apiserver-to-kubelet.yaml \
  root@server:~/
kube-apiserver                     100%   89MB  90.4MB/s   00:00
kube-controller-manager            100%   82MB  93.6MB/s   00:00
kube-scheduler                     100%   63MB 157.4MB/s   00:00
kubectl                            100%   55MB 153.5MB/s   00:00
kube-apiserver.service             100% 1374     1.6MB/s   00:00
kube-controller-manager.service    100%  735   936.9KB/s   00:00
kube-scheduler.service             100%  281   349.7KB/s   00:00
kube-scheduler.yaml                100%  191   231.0KB/s   00:00
kube-apiserver-to-kubelet.yaml     100%  727   952.4KB/s   00:00

Provision the Kubernetes control plane

root@server:~# mkdir -p /etc/kubernetes/config

Install the Kubernetes controller binaries

root@server:~# {
  mv kube-apiserver \
    kube-controller-manager \
    kube-scheduler kubectl \
    /usr/local/bin/
}

Configure the Kubernetes API Server

root@server:~# {
  mkdir -p /var/lib/kubernetes/

  mv ca.crt ca.key \
    kube-api-server.key kube-api-server.crt \
    service-accounts.key service-accounts.crt \
    encryption-config.yaml \
    /var/lib/kubernetes/
}

root@server:~# mv kube-apiserver.service \
  /etc/systemd/system/kube-apiserver.service

Configure the Kubernetes Controller Manager

root@server:~# mv kube-controller-manager.kubeconfig /var/lib/kubernetes/
root@server:~# mv kube-controller-manager.service /etc/systemd/system/

Configure the Kubernetes Scheduler

root@server:~# mv kube-scheduler.kubeconfig /var/lib/kubernetes/
root@server:~# mv kube-scheduler.yaml /etc/kubernetes/config/
root@server:~# mv kube-scheduler.service /etc/systemd/system/

Start the controller services

root@server:~# {
  systemctl daemon-reload

  systemctl enable kube-apiserver \
    kube-controller-manager kube-scheduler

  systemctl start kube-apiserver \
    kube-controller-manager kube-scheduler
}
Created symlink /etc/systemd/system/multi-user.target.wants/kube-apiserver.service → /etc/systemd/system/kube-apiserver.service.
Created symlink /etc/systemd/system/multi-user.target.wants/kube-controller-manager.service → /etc/systemd/system/kube-controller-manager.service.
Created symlink /etc/systemd/system/multi-user.target.wants/kube-scheduler.service → /etc/systemd/system/kube-scheduler.service.

API server verification

root@server:~# kubectl cluster-info \
  --kubeconfig admin.kubeconfig
Kubernetes control plane is running at https://127.0.0.1:6443

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

RBAC for kubelet authorization

This part just makes sure the API server is allowed to talk to the kubelet APIs on the worker nodes. As I understand it, the command here applies whatever's defined in kube-apiserver-to-kubelet.yaml to the cluster:

root@server:~# kubectl apply -f kube-apiserver-to-kubelet.yaml \
  --kubeconfig admin.kubeconfig
clusterrole.rbac.authorization.k8s.io/system:kube-apiserver-to-kubelet created
clusterrolebinding.rbac.authorization.k8s.io/system:kube-apiserver created

Verification

root@luger-VirtualBox:~/kubernetes-the-hard-way# curl --cacert ca.crt \
  https://server.kubernetes.local:6443/version
{
  "major": "1",
  "minor": "32",
  "gitVersion": "v1.32.3",
  "gitCommit": "32cc146f75aad04beaaa245a7157eb35063a9f99",
  "gitTreeState": "clean",
  "buildDate": "2025-03-11T19:52:21Z",
  "goVersion": "go1.23.6",
  "compiler": "gc",
  "platform": "linux/amd64"
}

TLS is working end-to-end. The jumpbox hit the API server over HTTPS using only the CA cert.

Summary

Setup the three control plane components: API server, controller manager, and scheduler as systemd services on the controller node, and placed RBAC so the API server can talk to kubelets on the workers.

[Lab Notes] Kubernetes the Hard Way, For Real This Time (Step 07)

Luger Lex Pit-og — Sun, 20 Sep 2026 19:14:17 +0000

Continuing my Kubernetes the Hard Way homelab build. Steps 01-06 are already done, this covers step 07.

Original guide: 07-bootstrapping-etcd.md

Thoughts I had while doing this

This step sets up the etcd cluster. From what I understand, etcd is basically Kubernetes' database, it's where the "state" of the whole cluster gets stored.

Quick TLDR before the actual steps:

grab the etcd binaries/service file

copy them over to the controller/server node

then install and configure etcd as a systemd service

End result: a running etcd Linux service on the controller.

So I basically just installed a database for Kubernetes.

Prerequisites

root@luger-VirtualBox:~/kubernetes-the-hard-way# scp \
  downloads/controller/etcd \
  downloads/client/etcdctl \
  units/etcd.service \
  root@server:~/
etcd        100%   24MB  92.2MB/s   00:00
etcdctl     100%   16MB 130.8MB/s   00:00
etcd.service

Install the etcd binaries

root@server:~# {
  mv etcd etcdctl /usr/local/bin/
}

Configure the etcd server

root@server:~# {
  mkdir -p /etc/etcd /var/lib/etcd
  chmod 700 /var/lib/etcd
  cp ca.crt kube-api-server.key kube-api-server.crt \
    /etc/etcd/
}
root@server:~# mv etcd.service /etc/systemd/system/

Start the etcd server

root@server:~# {
  systemctl daemon-reload
  systemctl enable etcd
  systemctl start etcd
}
Created symlink /etc/systemd/system/multi-user.target.wants/etcd.service → /etc/systemd/system/etcd.service.

Verification

root@server:~# etcdctl member list
6702b0a34e2cfd39, started, controller, http://127.0.0.1:2380, http://127.0.0.1:2379, false

etcd is up, and member list confirms it's running as a single-member cluster named controller.

Summary

Got etcd installed and running as a systemd service on the controller node, using the CA and API server certs from step 04 to secure it. Followed the guide as-is, no deviations this time.

[Lab Notes] Kubernetes the Hard Way, For Real This Time (Step 06)

Luger Lex Pit-og — Thu, 17 Sep 2026 16:08:28 +0000

Continuing my Kubernetes the Hard Way homelab build. Steps 01-05 are already done, this covers step 06.

Original guide: 06-data-encryption-keys.md

Thoughts I had while doing this

This step was pretty straightforward, just generate an encryption key and an encryption config file. But it did make me think back to step 04, where I set up the TLS/CA cert. Aren't both steps just "setting up encryption"? Kind of, but the difference is where the encryption applies:

Step 04 (TLS/CA) secures data in transit - traffic moving between Kubernetes components over the network.
Step 06 (encryption key) secures data at rest - specifically, Secrets stored in etcd(its like the db of kubernetes), so they're not sitting there in plain text on disk.

The encryption key

root@luger-VirtualBox:~/kubernetes-the-hard-way# export ENCRYPTION_KEY=$(head -c 32 /dev/urandom | base64)

The encryption config file

root@luger-VirtualBox:~/kubernetes-the-hard-way# envsubst < configs/encryption-config.yaml \
  > encryption-config.yaml
root@luger-VirtualBox:~/kubernetes-the-hard-way# scp encryption-config.yaml root@server:~/
encryption-config.yaml

Summary

Generated a random 32-byte encryption key and used it to fill in encryption-config.yaml, then copied that config to the controller. This is what encrypts Kubernetes Secrets at rest in etcd - separate from the TLS setup in step 04, which only covers data in transit.

[Lab Notes] Kubernetes the Hard Way, For Real This Time (Step 05)

Luger Lex Pit-og — Wed, 16 Sep 2026 21:45:37 +0000

Continuing my Kubernetes the Hard Way homelab build. Steps 1-4 are already done, this is for step 05.

Original guide: 05-kubernetes-configuration-files.md

Thoughts I had while doing this

This step is about creating kubeconfigs, basically the .conf files each Kubernetes service uses to know how to connect. Each service (scheduler, proxy, etc.) gets its own kubeconfig, and each one bundles in the cert files from step 04 so the connection to the API server (the control node) is authenticated and encrypted.

A gotcha along the way

Since I'm on Ubuntu instead of the guide's recommended Debian, I keep running into small differences. This step's version: my /etc/hosts changes from step 03 weren't surviving a reboot. Turned out Ubuntu's cloud-init manages /etc/hosts by default and quietly overwrites it:

# Your system has configured 'manage_etc_hosts' as True.
# As a result, if you wish for changes to this file to persist
# then you will need to either
# a.) make changes to the master file in /etc/cloud/templates/hosts.debian.tmpl
# b.) change or remove the value of 'manage_etc_hosts' in
#     /etc/cloud/cloud.cfg or cloud-config from user-data

Fixed it by updating the cloud-init template with the Kubernetes hostname entries instead of /etc/hosts directly:

# edited /etc/cloud/templates/hosts.debian.tmpl to include the Kubernetes host entries
sudo cloud-init clean --logs && sudo reboot

That made the entries persist across reboots.

Now here's the actual step.

Quick TLDR though: I just followed the guide to generate the kubeconfigs, and they worked as expected. Let me take a shot at explaining what these commands are actually doing.

Essentially, there are 4 commands run for each kubeconfig file, and all four are just pointed at that one file. Think of the kubeconfig as a plain text file, these commands just append to or edit pieces of it. That's really all that's happening:

set-cluster: adds the API server's URL and the CA cert, so the client knows who it's talking to and can verify it's really the API server.
set-credentials: adds the client's own cert and key, so the client can prove who it is to the API server.
set-context: bundles a cluster and a set of credentials together under a named context, so "use this identity to talk to this cluster" becomes one reusable label instead of two separate things. Basically, it just takes the outputs of set-cluster and set-credentials and bundles them together, that's really all set-context is doing.
use-context: sets that context as the active/default one, so any command using this kubeconfig automatically uses that cluster + credentials pair without you specifying them every time. Basically, you're just telling the kubeconfig "use the context I created in set-context as the default whenever a client loads this file."

The kubelet kubeconfig

root@luger-VirtualBox:~/kubernetes-the-hard-way# for host in node-0 node-1; do
  kubectl config set-cluster kubernetes-the-hard-way \
    --certificate-authority=ca.crt \
    --embed-certs=true \
    --server=https://server.kubernetes.local:6443 \
    --kubeconfig=${host}.kubeconfig

  kubectl config set-credentials system:node:${host} \
    --client-certificate=${host}.crt \
    --client-key=${host}.key \
    --embed-certs=true \
    --kubeconfig=${host}.kubeconfig

  kubectl config set-context default \
    --cluster=kubernetes-the-hard-way \
    --user=system:node:${host} \
    --kubeconfig=${host}.kubeconfig

  kubectl config use-context default \
    --kubeconfig=${host}.kubeconfig
done
Cluster "kubernetes-the-hard-way" set.
User "system:node:node-0" set.
Context "default" created.
Switched to context "default".
Cluster "kubernetes-the-hard-way" set.
User "system:node:node-1" set.
Context "default" created.
Switched to context "default".

The kube-proxy kubeconfig

root@luger-VirtualBox:~/kubernetes-the-hard-way# {
  kubectl config set-cluster kubernetes-the-hard-way \
    --certificate-authority=ca.crt \
    --embed-certs=true \
    --server=https://server.kubernetes.local:6443 \
    --kubeconfig=kube-proxy.kubeconfig

  kubectl config set-credentials system:kube-proxy \
    --client-certificate=kube-proxy.crt \
    --client-key=kube-proxy.key \
    --embed-certs=true \
    --kubeconfig=kube-proxy.kubeconfig

  kubectl config set-context default \
    --cluster=kubernetes-the-hard-way \
    --user=system:kube-proxy \
    --kubeconfig=kube-proxy.kubeconfig

  kubectl config use-context default \
    --kubeconfig=kube-proxy.kubeconfig
}
Cluster "kubernetes-the-hard-way" set.
User "system:kube-proxy" set.
Context "default" created.
Switched to context "default".

The kube-controller-manager kubeconfig

root@luger-VirtualBox:~/kubernetes-the-hard-way# {
  kubectl config set-cluster kubernetes-the-hard-way \
    --certificate-authority=ca.crt \
    --embed-certs=true \
    --server=https://server.kubernetes.local:6443 \
    --kubeconfig=kube-controller-manager.kubeconfig

  kubectl config set-credentials system:kube-controller-manager \
    --client-certificate=kube-controller-manager.crt \
    --client-key=kube-controller-manager.key \
    --embed-certs=true \
    --kubeconfig=kube-controller-manager.kubeconfig

  kubectl config set-context default \
    --cluster=kubernetes-the-hard-way \
    --user=system:kube-controller-manager \
    --kubeconfig=kube-controller-manager.kubeconfig

  kubectl config use-context default \
    --kubeconfig=kube-controller-manager.kubeconfig
}
Cluster "kubernetes-the-hard-way" set.
User "system:kube-controller-manager" set.
Context "default" created.
Switched to context "default".

The kube-scheduler kubeconfig

root@luger-VirtualBox:~/kubernetes-the-hard-way# {
  kubectl config set-cluster kubernetes-the-hard-way \
    --certificate-authority=ca.crt \
    --embed-certs=true \
    --server=https://server.kubernetes.local:6443 \
    --kubeconfig=kube-scheduler.kubeconfig

  kubectl config set-credentials system:kube-scheduler \
    --client-certificate=kube-scheduler.crt \
    --client-key=kube-scheduler.key \
    --embed-certs=true \
    --kubeconfig=kube-scheduler.kubeconfig

  kubectl config set-context default \
    --cluster=kubernetes-the-hard-way \
    --user=system:kube-scheduler \
    --kubeconfig=kube-scheduler.kubeconfig

  kubectl config use-context default \
    --kubeconfig=kube-scheduler.kubeconfig
}
Cluster "kubernetes-the-hard-way" set.
User "system:kube-scheduler" set.
Context "default" created.
Switched to context "default".

The admin kubeconfig

root@luger-VirtualBox:~/kubernetes-the-hard-way# {
  kubectl config set-cluster kubernetes-the-hard-way \
    --certificate-authority=ca.crt \
    --embed-certs=true \
    --server=https://127.0.0.1:6443 \
    --kubeconfig=admin.kubeconfig

  kubectl config set-credentials admin \
    --client-certificate=admin.crt \
    --client-key=admin.key \
    --embed-certs=true \
    --kubeconfig=admin.kubeconfig

  kubectl config set-context default \
    --cluster=kubernetes-the-hard-way \
    --user=admin \
    --kubeconfig=admin.kubeconfig

  kubectl config use-context default \
    --kubeconfig=admin.kubeconfig
}
Cluster "kubernetes-the-hard-way" set.
User "admin" set.
Context "default" created.
Switched to context "default".

Kubeconfig files generated

root@luger-VirtualBox:~/kubernetes-the-hard-way# ls -ltr *.kubeconfig
-rw------- 1 root root 10157 Sep 16 20:59 node-0.kubeconfig
-rw------- 1 root root 10161 Sep 16 20:59 node-1.kubeconfig
-rw------- 1 root root 10187 Sep 16 21:14 kube-proxy.kubeconfig
-rw------- 1 root root 10305 Sep 16 21:14 kube-controller-manager.kubeconfig
-rw------- 1 root root 10231 Sep 16 21:14 kube-scheduler.kubeconfig
-rw------- 1 root root  9953 Sep 16 21:14 admin.kubeconfig

Distribute the Kubernetes configuration files

root@luger-VirtualBox:~/kubernetes-the-hard-way# for host in node-0 node-1; do
  ssh root@${host} "mkdir -p /var/lib/{kube-proxy,kubelet}"

  scp kube-proxy.kubeconfig \
    root@${host}:/var/lib/kube-proxy/kubeconfig

  scp ${host}.kubeconfig \
    root@${host}:/var/lib/kubelet/kubeconfig
done

Summary

Step 05 built a kubeconfig for every cluster component that needs to talk to the API server, kubelet on each worker, kube-proxy, kube-controller-manager, kube-scheduler, and admin. Each one embedding the right cert/key from step 04 so the connection is authenticated. Also patched a Ubuntu-specific gotcha where cloud-init was silently reverting /etc/hosts changes on reboot.

[Lab Notes] Kubernetes the Hard Way, For Real This Time (Step 04)

Luger Lex Pit-og — Sun, 13 Sep 2026 20:22:17 +0000

Continuing my Kubernetes the Hard Way homelab build on Proxmox. Steps 01-03 are already done, this covers step 04.

Original guide: 04-certificate-authority.md

Thoughts I had while doing this

Before the actual step though, here are some stuff I learned or was thinking about along the way:

Kubernetes is starting to feel like a miniaturized version of an entire IT infrastructure. Compute already got abstracted from physical servers to containers. It's like Kubernetes took that same idea and asked "hey we already abstracted compute, why not abstract the whole infrastructure?"
Generating and installing all these certs felt exactly like setting up TLS between a bunch of servers so they can trust each other. Every Kubernetes component (API server, kubelet, etc.) is like another service on the network, and they all need to trust each other the same way any two servers would.

Anyways, here's Step 04:

Certificate Authority

Generated the CA key and self-signed CA certificate:

root@luger-VirtualBox:~/kubernetes-the-hard-way# {
  openssl genrsa -out ca.key 4096
  openssl req -x509 -new -sha512 -noenc \
    -key ca.key -days 3653 \
    -config ca.conf \
    -out ca.crt
}

Working directory at this point:

root@luger-VirtualBox:~/kubernetes-the-hard-way# ls -ltr
total 72
drwxr-xr-x 2 root root  4096 Sep  7 03:47 units
-rw-r--r-- 1 root root  2624 Sep  7 03:47 README.md
-rw-r--r-- 1 root root 11358 Sep  7 03:47 LICENSE
-rw-r--r-- 1 root root   839 Sep  7 03:47 downloads-arm64.txt
-rw-r--r-- 1 root root   839 Sep  7 03:47 downloads-amd64.txt
drwxr-xr-x 2 root root  4096 Sep  7 03:47 docs
-rw-r--r-- 1 root root   407 Sep  7 03:47 COPYRIGHT.md
-rw-r--r-- 1 root root  1059 Sep  7 03:47 CONTRIBUTING.md
drwxr-xr-x 2 root root  4096 Sep  7 03:47 configs
-rw-r--r-- 1 root root  5863 Sep  7 03:47 ca.conf
drwxr-xr-x 6 root root  4096 Sep  7 03:59 downloads
-rw-r--r-- 1 root root   163 Sep 10 04:05 machines.txt
-rw-r--r-- 1 root root   162 Sep 10 04:16 hosts
-rw------- 1 root root  3272 Sep 11 03:39 ca.key
-rw-r--r-- 1 root root  1899 Sep 11 03:39 ca.crt

No deviations here, followed the guide exactly.

Create client and server certificates

Generated a key, CSR, and signed cert for each Kubernetes component in one loop:

root@luger-VirtualBox:~/kubernetes-the-hard-way# certs=(
  "admin" "node-0" "node-1"
  "kube-proxy" "kube-scheduler"
  "kube-controller-manager"
  "kube-api-server"
  "service-accounts"
)
root@luger-VirtualBox:~/kubernetes-the-hard-way# for i in ${certs[*]}; do
  openssl genrsa -out "${i}.key" 4096

  openssl req -new -key "${i}.key" -sha256 \
    -config "ca.conf" -section ${i} \
    -out "${i}.csr"

  openssl x509 -req -days 3653 -in "${i}.csr" \
    -copy_extensions copyall \
    -sha256 -CA "ca.crt" \
    -CAkey "ca.key" \
    -CAcreateserial \
    -out "${i}.crt"
done

Confirmed all the expected files were generated:

root@luger-VirtualBox:~/kubernetes-the-hard-way# ls -1 *.crt *.key *.csr
admin.crt
admin.csr
admin.key
ca.crt
ca.key
kube-api-server.crt
kube-api-server.csr
kube-api-server.key
kube-controller-manager.crt
kube-controller-manager.csr
kube-controller-manager.key
kube-proxy.crt
kube-proxy.csr
kube-proxy.key
kube-scheduler.crt
kube-scheduler.csr
kube-scheduler.key
node-0.crt
node-0.csr
node-0.key
node-1.crt
node-1.csr
node-1.key
service-accounts.crt
service-accounts.csr
service-accounts.key

Also no deviations here, straight from the guide.

Distribute the client and server certificates

Copied the CA cert plus each worker's own cert/key to the right nodes:

root@luger-VirtualBox:~/kubernetes-the-hard-way# for host in node-0 node-1; do
  ssh root@${host} mkdir /var/lib/kubelet/

  scp ca.crt root@${host}:/var/lib/kubelet/

  scp ${host}.crt \
    root@${host}:/var/lib/kubelet/kubelet.crt

  scp ${host}.key \
    root@${host}:/var/lib/kubelet/kubelet.key
done

Got a "directory already exists" warning on both nodes, but the file copies all succeeded, so no issue:

mkdir: cannot create directory ‘/var/lib/kubelet/’: File exists
ca.crt        100% 1899     3.1MB/s   00:00
node-0.crt    100% 2147     3.9MB/s   00:00
node-0.key    100% 3268     6.7MB/s   00:00
mkdir: cannot create directory ‘/var/lib/kubelet/’: File exists
ca.crt        100% 1899     2.8MB/s   00:00
node-1.crt    100% 2147     3.1MB/s   00:00
node-1.key    100% 3272     5.1MB/s   00:00

Then copied the CA, API server, and service-account key/cert pairs to the controller (server):

root@luger-VirtualBox:~/kubernetes-the-hard-way# scp \
  ca.key ca.crt \
  kube-api-server.key kube-api-server.crt \
  service-accounts.key service-accounts.crt \
  root@server:~/
ca.key                  100% 3272     4.5MB/s   00:00
ca.crt                  100% 1899     5.0MB/s   00:00
kube-api-server.key     100% 3272     8.2MB/s   00:00
kube-api-server.crt     100% 2354     5.0MB/s   00:00
service-accounts.key    100% 3272     7.7MB/s   00:00
service-accounts.crt    100% 2004     3.9MB/s   00:00

Summary

Step 04 built out the cluster's PKI: a self-signed CA, then a key/cert pair for every component (admin, both worker nodes, kube-proxy, kube-scheduler, kube-controller-manager, kube-api-server, and service-accounts), distributed to the right machines.

[Lab Notes] Kubernetes the Hard Way, For Real This Time (Step 03)

Luger Lex Pit-og — Thu, 10 Sep 2026 16:04:45 +0000

Continuing my Kubernetes the Hard Way homelab build on Proxmox. Prerequisites and jumpbox setup (steps 01-02) are already done, this covers step 03 only.

Steps 01 and 02 were straightforward. Well, this one was a reminder that I'm doing this manually. No scripts or AI to automate all of the setup for me. Just me and the guide. And man, even if you have a guide but if you needed to tweak something in your setup. A whole bunch of problems pop up. It goes something like:

"Guide says do it this way, but I'm using a different tool, so I do it this way instead. Now something's broken because that tool needed extra config. Now the next step in the guide needs adjusting too."

It's like a row of light switches wired together. Flip one, and a few others flip with it. Now you've got to figure out which ones to switch back. But hey, thats exactly how Ops/Infra work is done(to me at least).

Anyway, here's how it went.

Machine database

Created machines.txt on the jumpbox, listing IP, FQDN, hostname, and pod subnet for each node:

root@luger-VirtualBox:~/kubernetes-the-hard-way# cat machines.txt
XXX.XXX.XXX.XXX k8s-solo.home.lab k8s-solo
XXX.XXX.XXX.XXX k8s-solo-w1.home.lab k8s-solo-w1 XXX.XXX.XXX.XXX/24
XXX.XXX.XXX.XXX k8s-solo-w2.home.lab k8s-solo-w2 XXX.XXX.XXX.XXX/24

(IPs are masked cuz I'm this 🤏 close to wearing a tin foil hat... even if they're internal IPs)

SSH access

Enabling root login: the guide assumes Debian, where root SSH login just needs to be turned on. On Ubuntu, root login is disabled by default too, so the fix was the same. Just edit sshd_config and restart the service:

ubuntu@k8s-solo:~$ sudo sed -i 's/^#*PermitRootLogin.*/PermitRootLogin yes/' /etc/ssh/sshd_config
ubuntu@k8s-solo:~$ sudo systemctl restart sshd

Generating and distributing keys: I originally planned to use root like the guide suggests, but kept hitting a Please login as the user "ubuntu" rather than the user "root" prompt on every node. I didn't bother digging into it right away, so it wasn't until the end of this step that I actually tracked down why. Ubuntu's cloud images bake a forced command into /root/.ssh/authorized_keys that blocks direct root SSH login and prints that message instead. Rather than fight it, I just switched to the ubuntu user for all admin access. So keys were copied to ubuntu@ on each node instead of root@. Also used a dedicated keypair instead of overwriting any existing id_rsa:

root@luger-VirtualBox:~/kubernetes-the-hard-way# ssh-keygen
Enter file in which to save the key (/root/.ssh/id_rsa): /root/.ssh/id_rsa_kthw

root@luger-VirtualBox:~/kubernetes-the-hard-way# while read IP FQDN HOST SUBNET; do
  ssh-copy-id -i /root/.ssh/id_rsa_kthw.pub ubuntu@${IP}
done < machines.txt

Verified access to all three nodes:

root@luger-VirtualBox:~/kubernetes-the-hard-way# while read IP FQDN HOST SUBNET; do
  ssh -n ubuntu@${IP} hostname
done < machines.txt
k8s-solo
k8s-solo-w1
k8s-solo-w2

Hostnames

The guide sets each machine's hostname to match its role: server, node-0, node-1. I updated machines.txt accordingly and ran the rename commands against the ubuntu user instead of root:

root@luger-VirtualBox:~/kubernetes-the-hard-way# while read IP FQDN HOST SUBNET; do
    CMD="sudo sed -i 's/^127.0.1.1.*/127.0.1.1\t${FQDN} ${HOST}/' /etc/hosts"
    ssh -n ubuntu@${IP} "$CMD"
    ssh -n ubuntu@${IP} sudo hostnamectl set-hostname ${HOST}
    ssh -n ubuntu@${IP} sudo systemctl restart systemd-hostnamed
done < machines.txt

Confirmed:

root@luger-VirtualBox:~/kubernetes-the-hard-way# while read IP FQDN HOST SUBNET; do
  ssh -n ubuntu@${IP} hostname --fqdn
done < machines.txt
server.kubernetes.local
node-0.kubernetes.local
node-1.kubernetes.local

From this point on, the nodes are addressed as server, node-0, and node-1 per the guide's convention. Not the earlier k8s-solo / k8s-solo-w1 / k8s-solo-w2 names.

Host lookup table

No surprises here, followed the guide as-is. Built a hosts file on the jumpbox and appended it to the jumpbox's own /etc/hosts:

root@luger-VirtualBox:~/kubernetes-the-hard-way# echo "# Kubernetes The Hard Way" >> hosts
root@luger-VirtualBox:~/kubernetes-the-hard-way# while read IP FQDN HOST SUBNET; do
    echo "${IP} ${FQDN} ${HOST}" >> hosts
done < machines.txt
root@luger-VirtualBox:~/kubernetes-the-hard-way# cat hosts >> /etc/hosts

Verified hostname resolution works locally:

root@luger-VirtualBox:~/kubernetes-the-hard-way# for host in server node-0 node-1; do ssh ubuntu@${host} hostname; done
server
node-0
node-1

Adding `/etc/hosts` entries to the remote machines

Had to adjust the guide's command here too, same reason as before (ubuntu user instead of root), plus a gotcha with sudo and output redirection:

root@luger-VirtualBox:~/kubernetes-the-hard-way# while read IP FQDN HOST SUBNET; do
  scp hosts ubuntu@${HOST}:~/
  ssh -n ubuntu@"${IP}" "sudo sh -c 'cat hosts >> /etc/hosts'"
done < machines.txt

Interesting nugget of info I learned here: sudo somecommand >> file doesn't work the way you'd expect, sudo only elevates the command itself, not the >> redirection. The redirection is set up by your current shell before sudo ever runs, so it still tries to write as your regular user. Wrapping the whole thing in sudo sh -c '...' fixes it, since now the shell doing the redirecting is the one running as root.

Summary

Step 03 set up the actual infrastructure: root/admin SSH access between the jumpbox and all three nodes, and consistent hostnames (server, node-0, node-1) so every machine can address the others by name instead of IP.

[Lab Notes] Kubernetes the Hard Way, For Real This Time (Steps 01-02)

Luger Lex Pit-og — Mon, 07 Sep 2026 19:27:17 +0000

Following Kelsey Hightower's Kubernetes the Hard Way, but on my own Proxmox homelab. These are my notes on what I did and what's different from the original guide.

Why I'm doing this

As a DevOps engineer, I wanted to actually understand Kubernetes instead of just knowing the commands. My real question going in was: why do we even need Kubernetes? If containers already package and run our apps, isn't that enough?

My first attempt was to just spin up a cluster with AI/scripts doing most of the work. I provisioned a 1+2 node k3s cluster on this same Proxmox homelab:

k3sup and kubectl installed on a WSL workstation
k3s control plane running on k3s-cp
Both worker nodes joined and healthy
Cilium CNI v1.19.3 installed, all 3 nodes Ready
kubeconfig merged and working on the WSL workstation

It worked. But I didn't understand jack of what I built. So I scrapped that and started over with Kubernetes the Hard Way instead, building each piece by hand.

Environment

Host	Role	OS	Memory
`UbuntuDesktop-Sandbox1`	Jumpbox	Ubuntu 22.04 LTS (Jammy)	16GB
`k8s-solo`	Controller	Ubuntu Server 22.04.5 LTS	4 GB
`k8s-solo-w1`	Worker 1	Ubuntu Server 22.04.5 LTS	2 GB
`k8s-solo-w2`	Worker 2	Ubuntu Server 22.04.5 LTS	2 GB

All VMs run on Proxmox. The jumpbox is an existing Ubuntu sandbox VM I already had, repurposed for this project. Static IPs and hostnames are set for all four VMs, and SSH keys are already set up from the jumpbox to all three nodes.

Topology is 1 controller + 2 workers.

01 - Prerequisites

kubectl is installed on the jumpbox:

root@luger-VirtualBox:~/kubernetes-the-hard-way/downloads# kubectl version --client
Client Version: v1.32.3
Kustomize Version: v5.5.0

02 - Jumpbox

Repo cloned to:

root@luger-VirtualBox:~/kubernetes-the-hard-way# pwd
/root/kubernetes-the-hard-way

Binaries downloaded into downloads/:

root@luger-VirtualBox:~/kubernetes-the-hard-way/downloads# ls -ltr
total 16
drwxr-xr-x 2 root root 4096 Jan  7  2025 cni-plugins
drwxr-xr-x 2 root root 4096 Sep  7 03:59 controller
drwxr-xr-x 2 root root 4096 Sep  7 03:59 client
drwxr-xr-x 2 root root 4096 Sep  7 03:59 worker

SSH from the jumpbox to k8s-solo, k8s-solo-w1, and k8s-solo-w2 is already working with key-based auth, no passwords.

[Quick Notes] "Docker-fying" my Portfolio Website

Luger Lex Pit-og — Thu, 03 Sep 2026 19:31:04 +0000

Notes to my future self, in plain English.

What I Was Trying To Do

I already had my portfolio website working on my computer using Hugo and a template for the design. I wanted to package it up in Docker so I could run it the same way anywhere, instead of relying on my machine's setup.

Lesson 1: Hugo Doesn't Actually "Run" a Website

When I ran hugo server on my computer, it felt like a website was "running." But that command is really just a preview tool for editing. It's not meant to be used for real, live traffic.
The command hugo --minify does something different: it takes all my content and the template and converts it into plain files — HTML, CSS, images — and dumps them in a folder called public/. Then it stops. Nothing is left running. It's like exporting a Word doc to PDF — a one-time conversion, not an app that stays open.

So a real website needs two separate things:

Something to build the files (Hugo).
Something to serve those files to visitors (a web server — I used nginx).

That's why my Docker setup has two stages.

Lesson 2: The Two-Stage Dockerfile

FROM hugomods/hugo:exts AS build
WORKDIR /src
COPY . .
RUN hugo --minify

FROM nginx:alpine
COPY --from=build /src/public /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

Think of it as two mini-containers glued together:

First part: a temporary workspace with Hugo installed. It builds my site into plain files.
Second part: a clean, lightweight container with just nginx (the web server). It grabs the finished files from the first part and throws away everything else — no Hugo, no build tools, just the website files and something to hand them out.

Lesson 3: My Template Needed an Extra Build Step

My first build failed. After digging in, the real problem was simple: my Hugo template also needed some JavaScript/CSS tooling (npm) to build properly, and I wasn't running that step. Without it, the template's styling code came up empty and broke the build.

Fix: install Node.js in the build stage and run the extra setup commands before building the site:

FROM hugomods/hugo:exts AS build
WORKDIR /src
RUN apk add --no-cache nodejs npm
COPY . .
RUN hugo mod npm pack && npm install
RUN hugo --minify

FROM nginx:alpine
COPY --from=build /src/public /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

Takeaway: if a template comes with its own JavaScript/CSS setup, I need to run that setup too — Hugo alone won't do it automatically.

Lesson 4: Ports Are Confusing At First

Two separate mistakes here:

Mistake A: I typed -p 80:8080, but Docker's format is -p my_computer_port:container_port. Nginx inside the container listens on port 80, so the second number always has to be 80 — no matter what port I want to use on my own machine.

Mistake B: Even after fixing that, port 80 on my actual computer was already being used by something else. Easiest fix: just pick a different, unused port on my side.

docker run -p 8888:80 portfolio

Takeaway: the EXPOSE line in a Dockerfile is just a note for humans — it doesn't control anything. The real listening port comes from nginx's own settings.

Lesson 5: The `/cv` Page Redirect Bug

Visiting mysite.com/cv sent me somewhere broken.

Turns out this was expected behavior gone slightly wrong: Hugo saves that page as a folder (/cv/index.html), so nginx automatically redirects /cv to /cv/. That part's normal.

The bug was that nginx was guessing the wrong port when building that redirect, it assumed port 80 (the port inside the container) instead of 8888 (the port I was actually using on my computer). So it sent my browser to the wrong address.

Fix: tell nginx not to guess the full address, just use a relative path:

server {
    listen 80;
    server_name _;
    absolute_redirect off;

    root /usr/share/nginx/html;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

And load that file into the container:

COPY nginx.conf /etc/nginx/conf.d/default.conf

The Final Setup

Dockerfile:

FROM hugomods/hugo:exts AS build
WORKDIR /src
RUN apk add --no-cache nodejs npm
COPY . .
RUN hugo mod npm pack && npm install
RUN hugo --minify

FROM nginx:alpine
COPY --from=build /src/public /usr/share/nginx/html
COPY nginx.conf /etc/nginx/conf.d/default.conf
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

nginx.conf:

server {
    listen 80;
    server_name _;
    absolute_redirect off;

    root /usr/share/nginx/html;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

.dockerignore:

public/
resources/
.git/
node_modules/

To run it:

docker build -t portfolio .
docker run -p 8888:80 portfolio

The Short Version, In Plain Words

Hugo builds a website into files. It doesn't keep a website "running" — that's nginx's job.
A Docker build can use one big toolbox to build something, then hand the finished result to a small, clean container to actually serve it.
Some templates need an extra JavaScript/CSS setup step — don't skip it.
EXPOSE in a Dockerfile is just a label. The real port comes from the app's own settings.
When mapping ports, the right-hand number always has to match what the app inside is really listening on.
Redirects inside a container can point to the wrong port if you don't tell the web server to keep them relative.

[Quick Notes] Growing My Ubuntu VM's Boot Disk

Luger Lex Pit-og — Thu, 03 Sep 2026 19:00:47 +0000

Made the VM disk bigger and had to tell the OS to actually use the extra space. Took 3 steps.

1. Grow the disk (hypervisor side)

Resized the virtual disk in Proxmox/VirtualBox, adding extra space (e.g. +20G). OS doesn't see it yet.

2. Grow the partition

sudo apt install cloud-guest-utils
sudo growpart /dev/vda 3

growpart stretches a partition to fill new space.
The 3 is the partition number (from lsblk), not part of the disk name.
Ignored an unrelated shim-signed error during install — didn't affect anything.

3. Grow the filesystem

Checked for LVM first:

sudo pvresize /dev/vda3

Got "command not found" → no LVM here, skip it.

Then resized the filesystem directly:

sudo resize2fs /dev/vda3

(Use xfs_growfs / instead if filesystem is XFS, not ext4.)

4. Confirm

df -h /

Showed full new size. And we're done! No reboot needed.

Cheat sheet

Check disk/partitions	`lsblk`
Check filesystem usage	`df -h /`
Grow partition	`sudo growpart /dev/vda 3`
Grow filesystem (ext4)	`sudo resize2fs /dev/vda3`
Grow filesystem (XFS)	`sudo xfs_growfs /`

Remember

Back up/snapshot before resizing.
"Command not found" on LVM tools = you're not using LVM, that's fine.
Whole thing can be done live, no reboot.

[Quick Notes] RDP Into a Proxmox VM Without Opening It Up to the Network

Luger Lex Pit-og — Thu, 03 Sep 2026 16:08:29 +0000

I run an Ubuntu Desktop VM on my Proxmox server and wanted to RDP into it without exposing port 3389 to my whole network. What i ended up with: tunnel RDP through SSH.

The Idea

I already trust my SSH connection to the Proxmox host. So instead of opening RDP up directly, I have SSH secretly carry the RDP traffic for me:

[Laptop] --localhost:3389--> [SSH tunnel] --> [Proxmox host] --3389--> [VM]

My RDP client just connects to localhost:3389 like normal. It has no idea SSH is quietly relaying that traffic all the way to the VM.

Setup

VM side: install and run xrdp like usual.

Laptop side, add this to ~/.ssh/config:

Host proxmox-rdp
    HostName <proxmox-host-ip>
    User <your-user>
    LocalForward 3389 <VM_IP>:3389

That LocalForward line forwards local port 3389 to the VM's port 3389.

Connecting

1.Start the VM in Proxmox.
2.Open the tunnel(ran on my client):

   ssh proxmox-rdp -N

(-N = just forward the port. It'll look frozen. That's normal, just leave it open.)

3.RDP to localhost:3389.

Close that terminal, tunnel's gone, RDP stops working.

Why Bother

Only SSH needs to be exposed, not RDP. All the traffic rides inside SSH's encryption.

Watch Out For

If the VM's IP is DHCP and changes after a reboot, the LocalForward line goes stale. Set a static IP or DHCP reservation to avoid this.

[2026] Passed the AWS Certified Security Specialty (SCS-C03)

Luger Lex Pit-og — Wed, 02 Sep 2026 16:47:26 +0000

Result: Passed - Score: 831

A quick log of how I prepped for and passed the AWS Security Specialty exam.

Background

DevOps/Cloud Engineer, 5+ years of experience
~2-3 years hands-on with AWS
AWS Certs held before attempting SCS-C03:
- AWS Certified Solutions Architect - Associate (Oct 2025)
- AWS Certified CloudOps Engineer - Associate (Jan 2026)

So yeah, I already had some XP with AWS and got 2x Associate-level certs before attempting the Security Specialty.

Timeline

~2 months, on and off - Struggled a bit with staying consistent in trying to finish the Udemy Courses. Kept starting and stopping without finishing them.

Final 3 weeks, locked in - Annoyed at my progress with the Udemy Courses, I switched entirely to using Practice Exams. Found it more interactive. This is where things actually clicked and prep became consistent.

Lesson learned: For a cert like this (with real AWS experience already backing it up), practice-exam prep was far more effective for me.

Study Resources

Primary: Practice Exams

Tutorials Dojo – AWS Certified Security Specialty Practice Exams (SCS-C03) This was the backbone of my prep, especially in the final 3 weeks. I went ahead and did a consistent grind and review of all the questions. If I made a mistake, I took note of it. Why I was wrong, what the correct answer was. If I still didn't get it, I asked AI to dumb it down until I did. Here's my Practice Exam Logs before actually taking the exam.

Practice Exam	Score	Date
Randomized Test	52.31%	Jul 6, 2026
Review Mode Set 1	75.71%	Jul 30, 2026
Review Mode Set 2	65.71%	Aug 1, 2026
Review Mode Set 3	64.62%	Aug 9, 2026
Randomized Test	89.23%	Aug 9, 2026
Randomized Test	89.23%	Aug 11, 2026
Timed Mode Set 2	90.77%	Aug 14, 2026
Timed Mode Set 1	89.23%	Aug 14, 2026

Supplementary: Video Courses (targeted, not full playthroughs)

Used these reactively. I'd just search a topic on their courses where I was weak at, then watch that. Maarek courses are a given when doing AWS Cert Preps. But Zeal Vora's course, although quite lengthy, was kinda fun to watch. The guy sometimes goes off on tangents and tells anecdotes from his industry experience and how it relates to the topic at hand.

Ultimate AWS Certified Security Specialty [NEW 2026] SCS-C03 — Stephane Maarek
[NEW] AWS Certified Security Specialty 2026 — Zeal Vora

AI-Assisted Deep Dives

So AI obviously is a must nowadays. When I didn't get something, I'd use AI to further break it down, ask follow-up questions, get analogies, or clarify edge cases until it stuck.

Staying Motivated

Every time I felt a bit down with my progress, I'd just lurk on the r/AWSCertifications sub. Seeing other folks in the trenches, sharing their prep, posting their pass stories, honestly hit different. Gave me that "if they can do it, so can I" push to lock back in.

What Worked

Practice exams > passive video watching.
Targeted topic review
AI as a tutor
Prior hands-on AWS experience made a real difference.

What I'd Do Differently

Start the practice-exam-heavy approach earlier instead of spending the first ~6 weeks trying to grind through full video courses.

Takeaway

I already had the hands-on AWS experience. I already had 2x AWS Associate Certs going in. So really, I should've just trusted that and gone straight to practice exams to find my weak spots, instead of grinding through full courses first. This is what worked for me. If you're already coming in with real AWS experience, don't sleep on practice exams.

Running Tiny LLMs on Your Local Machine with vLLM + WSL2 (No Cloud Needed!)

Luger Lex Pit-og — Thu, 03 Jul 2025 16:40:33 +0000

“Surely my gaming laptop can handle a 7B model, right?”
— Me, before reality hit me like an OOM error.

So here’s the story: I dove into the world of local LLMs thinking my Lenovo Legion 5i Gaming Laptop—rocking 6GB of VRAM, 32GB of RAM, and a solid Intel i7 CPU could surely handle running a local LLM right? I figured, “Let’s try running Mistral-7B locally. Psssh, what could go wrong?”

Everything. Everything went wrong.

The moment I tried, my GPU begged for mercy, RAM usage spiked like it saw a ghost, and the model refused to even load. That's when I realized something important: bigger isn’t always better, especially when it comes to LLMs and local hardware.

But hey, that failure was a blessing in disguise. It led me to the world of tiny but mighty LLMs—specifically TinyLlama—paired with the vLLM inference engine, which is optimized for performance and memory efficiency. This combo actually works on my hardware, and it might work for yours too.

If you're in the same boat—curious about LLMs, want to run them locally, but don't have an RTX 4090 lying around—then this guide is for you.

Let’s get into it. 👇

Why Bother with Local "Tiny" vLLMs?

Running AI models locally has a lot of benefits:

No OpenAI/HuggingFace API costs
Full control over the system
Great for testing, hacking, or even building apps offline
You learn a LOT more doing it this way

But we're also being realistic here—if you're like me and you're not running an RTX 4090, you need something that fits your hardware. That's why I'm using TinyLlama—a small but capable model—and leveraging vLLM, a super-efficient inference engine built for LLMs.

🛠 Step-by-Step: How I Set It Up

1. Install WSL2
First things first, we need WSL2 set up. I didn’t go through the Microsoft Store route—just used good old command line.

Open PowerShell as Administrator and run:

wsl --install

That installs WSL2 along with the default Ubuntu distro. If you want a specific Ubuntu version (like 20.04), you can install it with:

wsl --install -d Ubuntu-20.04

Reboot if necessary.

2. Launch Ubuntu and Prep Your Environment
Once Ubuntu is installed, launch it via your Start Menu or run wsl from a terminal. From here, it’s just regular Linux commands.

Inside Ubuntu, I did the usual system update and installed Python tools:

sudo apt update && sudo apt upgrade -y
sudo apt install python3 python3-pip python3-venv -y

Next, I set up a Python virtual environment for this project:

python3 -m venv vllm-env
source vllm-env/bin/activate
pip install --upgrade pip

3. Run vLLM with TinyLlama
Now we launch the vLLM API server with TinyLlama. This runs a local OpenAI-compatible endpoint:

python -m vllm.entrypoints.openai.api_server \
  --model TinyLlama/TinyLlama-1.1B-Chat-v1.0 \
  --host 0.0.0.0 \
  --port 8000 \
  --gpu-memory-utilization 0.7

What these flags mean:
--model: Specifies the model from Hugging Face
--host 0.0.0.0: Exposes the API to your host machine
--port 8000: Runs it on port 8000
--gpu-memory-utilization 0.7: Only uses 70% of your GPU’s memory (you can tweak this)

Testing It
Once it’s up and running, try hitting the endpoint from your browser or a tool like Postman:

http://localhost:8000/docs

You can use it like the OpenAI API—just pass in your prompt, model name, and get a response.

Wrapping Up

So yeah—turns out you can run LLMs locally, just don’t expect your laptop to handle a 7B model without crying. TinyLlama + vLLM is a great combo for tinkering and learning without frying your GPU.

Now that it’s running, I’ll be hacking away at this black-box AI, trying to make it actually follow my prompts—especially when I ask for a specific word count (seriously, why is that so hard?).

More experiments to come. Stay tuned!

DEV Community: Luger Lex Pit-og

[Lab Notes] Kubernetes the Hard Way, For Real This Time (Step 08)

Thoughts I had while doing this

A gotcha along the way: apiserver wouldn't start

Prerequisites

Provision the Kubernetes control plane

Install the Kubernetes controller binaries

Configure the Kubernetes API Server

Configure the Kubernetes Controller Manager

Configure the Kubernetes Scheduler

Start the controller services

API server verification

RBAC for kubelet authorization

Verification

Summary

[Lab Notes] Kubernetes the Hard Way, For Real This Time (Step 07)

Thoughts I had while doing this

Prerequisites

Install the etcd binaries

Configure the etcd server

Start the etcd server

Verification

Summary

[Lab Notes] Kubernetes the Hard Way, For Real This Time (Step 06)

Thoughts I had while doing this

The encryption key

The encryption config file

Summary

[Lab Notes] Kubernetes the Hard Way, For Real This Time (Step 05)

Thoughts I had while doing this

A gotcha along the way

Now here's the actual step.

The kubelet kubeconfig

The kube-proxy kubeconfig

The kube-controller-manager kubeconfig

The kube-scheduler kubeconfig

The admin kubeconfig

Kubeconfig files generated

Distribute the Kubernetes configuration files

Summary

[Lab Notes] Kubernetes the Hard Way, For Real This Time (Step 04)

Thoughts I had while doing this

Certificate Authority

Create client and server certificates

Distribute the client and server certificates

Summary

[Lab Notes] Kubernetes the Hard Way, For Real This Time (Step 03)

Machine database

SSH access

Hostnames

Host lookup table

Adding /etc/hosts entries to the remote machines

Summary

[Lab Notes] Kubernetes the Hard Way, For Real This Time (Steps 01-02)

Why I'm doing this

Environment

01 - Prerequisites

02 - Jumpbox

[Quick Notes] "Docker-fying" my Portfolio Website

What I Was Trying To Do

Lesson 1: Hugo Doesn't Actually "Run" a Website

Lesson 2: The Two-Stage Dockerfile

Lesson 3: My Template Needed an Extra Build Step

Lesson 4: Ports Are Confusing At First

Lesson 5: The /cv Page Redirect Bug

The Final Setup

The Short Version, In Plain Words

[Quick Notes] Growing My Ubuntu VM's Boot Disk

1. Grow the disk (hypervisor side)

2. Grow the partition

3. Grow the filesystem

4. Confirm

Cheat sheet

Remember

[Quick Notes] RDP Into a Proxmox VM Without Opening It Up to the Network

The Idea

Setup

Connecting

Why Bother

Watch Out For

Adding `/etc/hosts` entries to the remote machines

Lesson 5: The `/cv` Page Redirect Bug