DEV Community: Sergio Peris

How to upgrade a MicroK8s cluster

Sergio Peris — Mon, 20 Jul 2026 09:00:22 +0000

For this tutorial, we'll use a 3-node MicroK8s cluster with nodes k8s-1, k8s-2, and k8s-3.

microk8s kubectl get nodes

NAME    STATUS   ROLES    AGE    VERSION
k8s-1   Ready    <none>   142d   v1.35.6
k8s-2   Ready    <none>   142d   v1.35.6
k8s-3   Ready    <none>   142d   v1.35.6

Upgrade the first node

To upgrade a node, we must cordon it first so new pods cannot be scheduled on it.

microk8s kubectl cordon k8s-1

node/k8s-1 cordoned

If we get the node list again, we can see that it now has pod scheduling disabled.

microk8s kubectl get nodes

NAME    STATUS                     ROLES    AGE    VERSION
k8s-1   Ready,SchedulingDisabled   <none>   142d   v1.35.6
k8s-2   Ready                      <none>   142d   v1.35.6
k8s-3   Ready                      <none>   142d   v1.35.6

Next, we must remove the remaining pods on this node by draining it.

microk8s kubectl drain k8s-1 --ignore-daemonsets --delete-emptydir-data

node/k8s-1 already cordoned
Warning: ignoring DaemonSet-managed Pods: ingress/traefik-zgvnx, kube-system/calico-node-2nlwf
evicting pod sertxudev/sertxudev-worker-86d556b9cd-f5nhw
evicting pod postgresql/postgresql-cluster-3
evicting pod sertxudev/sertxudev-app-7d46bdbbcc-977lf
evicting pod sertxudev/sertxudev-scheduler-5996645758-8fsht
pod/postgresql-cluster-3 evicted

We can check that our node no longer has pods, except from the required base ones.

microk8s kubectl get pods -A --field-selector spec.nodeName=k8s-1

NAMESPACE     NAME                READY   STATUS    RESTARTS   AGE
ingress       traefik-zgvnx       1/1     Running   0          142d
kube-system   calico-node-2nlwf   1/1     Running   0          17d

Now that our node is empty, we can proceed with the upgrade. It's recommended to upgrade one minor version at a time. You can review the latest MicroK8s version on GitHub releases
.

Ensure you're connected to the node you want to upgrade. Previous commands can be run from any K8s node, but snap refresh should be run in the node you want to upgrade.

snap refresh microk8s --channel 1.36/stable

microk8s (1.36/stable) v1.36.2 from Canonical✓ refreshed

Once the MicroK8s snap has been upgraded, we can let K8s start creating pods in our node by uncordoning it.

microk8s kubectl uncordon k8s-1

node/k8s-1 uncordoned

If we check the cluster nodes again, we can see that our current node has been updated.

kubectl get nodes

NAME    STATUS   ROLES    AGE    VERSION
k8s-1   Ready    <none>   142d   v1.36.2
k8s-2   Ready    <none>   142d   v1.35.6
k8s-3   Ready    <none>   142d   v1.35.6

Once the upgraded node is ready to receive pods again, we can begin to upgrade the next node. By running the same commands we've just seen for the next node until all nodes are upgraded.

Rebalance deployments

Once our cluster is up-to-date, we might want to rebalance our deployments so pods are spread among all nodes.

kubectl get nodes

NAME    STATUS   ROLES    AGE    VERSION
k8s-1   Ready    <none>   142d   v1.36.2
k8s-2   Ready    <none>   142d   v1.36.2
k8s-3   Ready    <none>   142d   v1.36.2

First, we should get the deployments that our cluster hosts.

microk8s kubectl get deployments -A

NAMESPACE      NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
cert-manager   cert-manager              1/1     1            1           441d
cert-manager   cert-manager-cainjector   1/1     1            1           441d
cert-manager   cert-manager-webhook      1/1     1            1           441d
cnpg-system    barman-cloud              1/1     1            1           333d
cnpg-system    cnpg-controller-manager   1/1     1            1           333d
kube-system    calico-kube-controllers   1/1     1            1           454d
kube-system    coredns                   1/1     1            1           454d
kube-system    hostpath-provisioner      1/1     1            1           448d
kube-system    metrics-server            1/1     1            1           444d
sertxudev      sertxudev-app             2/2     2            2           200d
sertxudev      sertxudev-scheduler       1/1     1            1           420d
sertxudev      sertxudev-worker          1/1     1            1           420d

Next, we restart the rollout of each deployment we want to rebalance.

kubectl rollout restart deployment -n sertxudev sertxudev-app
kubectl rollout restart deployment -n sertxudev sertxudev-scheduler
kubectl rollout restart deployment -n sertxudev sertxudev-worker

deployment.apps/sertxudev-app restarted
deployment.apps/sertxudev-scheduler restarted
deployment.apps/sertxudev-worker restarted

Now we have an up-to-date MicroK8s cluster ready to continue serving traffic as usual.

Sync Windows server time using NTP server

Sergio Peris — Thu, 02 Jul 2026 09:00:22 +0000

We have a few scheduled tasks running on a Windows server and monitored by a self-hosted Sentry instance.

Sentry was reporting to us about missed check-ins. Looking at the monitor details, we've noticed the scheduled task was being dispatched early. So the expected dispatch at the start of every minute (0 * * * *) was never fulfilled.

Visiting the website time.is from the Windows server we’ve identified that our clock was 5 seconds ahead.

This explains why our scheduled tasks were dispatched early, but we had to know why our clock wasn't synchronized.

Using PowerShell, first we check the status of the Windows time service:

w32tm /query /status

Indicador de salto: 0(ninguna advertencia)
Capa: 4 (referencia secundaria - sincronizada mediante (S)NTP)
Precisión: -23 (119.209ns por tick)
Demora de raíz: 5.0620658s
Dispersión de raíz: 5.1932719s
Id. de referencia: 0xC0A801FC (IP de origen:  192.168.1.252)
Última sincronización de hora correcta: 01/07/2026 13:02:11
Origen: DC1.sertxu.local
Intervalo de sondeo: 12 (4096s)

As we can see, our server depends on DC1.sertxu.local for the clock synchronization.

Currently, our scheduler server is synchronizing with DC1, which also seems to have a time drift.

Let's check the time service on DC1:

w32tm /query /status

Indicador de salto: 0(ninguna advertencia)
Capa: 4 (referencia secundaria - sincronizada mediante (S)NTP)
Precisión: -23 (119.209ns por tick)
Demora de raíz: 5.0620658s
Dispersión de raíz: 5.1163169s
Id. de referencia: 0xC0A801FC (IP de origen:  192.168.1.252)
Última sincronización de hora correcta: 01/07/2026 13:28:43
Origen: DC1.sertxu.local
Intervalo de sondeo: 10 (1024s)

That's kind of strange! Our DC1 server depends on itself for clock synchronization, and also has a 5-second drift. That doesn't seem right.

By default, when a Windows device joins a domain, it starts synchronizing its time with the domain servers.

But we have to make sure the primary domain server (PDC Emulator) synchronizes its time with a reliable external NTP server.

First, we have to make sure our DC1 is the primary domain server:

netdom query fsmo

Maestro de esquema          DC1.sertxu.local
Maestro nomencl. dominios   DC1.sertxu.local
PDC                         DC1.sertxu.local
Administrador de grupos RID DC1.sertxu.local
Maestro de infraestructura  DC1.sertxu.local
El comando se completó correctamente.

To start synchronizing with an external NTP server, we have to update the Windows time service configuration:

w32tm /config /manualpeerlist:"pool.ntp.org" /syncfromflags:manual /reliable:yes /update

And then restart the service:

net stop w32time
net start w32time

Now our DC1 will synchronize its time with the NTP server pool and will eventually solve its time drift.

But what will happen with the other servers and computers joined to the domain? Because our DC1 is our primary domain server, the other devices that depend on DC1 will also start to solve the time drift, so after a few minutes all devices will be in sync with the NTP server pool.

Deploying a FastAPI app to Kubernetes with health probes

Sergio Peris — Mon, 04 May 2026 09:00:24 +0000

This week, I was updating the image of a FastAPI app in our Kubernetes cluster, but I took the whole app down because the process failed due to an incompatible dependency with our server. The updated pod was unable to start, but we didn't have health checks in place, so the deployment continued to update the other replicas, taking down all app instances.

In this tutorial, I will explain how to add a health check to your FastAPI app to ensure the deployment doesn't continue updating the pods if they fail.

Adding a health endpoint to your FastAPI app

Kubernetes requires two endpoints, liveness and readiness. What's the difference between them?

Liveness endpoint: Should return a 200 OK as long as the app is running.
Readiness endpoint: Should return a 200 OK when the app is ready to handle traffic.

If your app takes some time from boot since it's ready to start handling traffic, it makes sense to have two different endpoints. This also prevents Kubernetes from killing the updated pod while it's still booting.

For this tutorial, we will create only one endpoint at /health. This is a minimal FastAPI app:

from fastapi import FastAPI

app = FastAPI()

@app.get("/health")
def health_check():
    return {"status": "OK"}

Containerizing the app

To run this app in Kubernetes, you should create a Docker image. This is a basic image:

FROM python:3.13-slim

WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY main.py .

EXPOSE 8000

CMD ["uvicorn", "main:app", "--log-level", "warning", "--host", "0.0.0.0", "--port", "8000"]

The requirements.txt file only needs fastapi and uvicorn for this example.

Then we build the Docker image, and push it to a registry your Kubernetes cluster can access, like Docker Hub or a private registry.

docker build -t fastapi-health-app:latest .

Kubernetes deployment manifest

To deploy the app in your Kubernetes cluster, you need to create a deployment manifest.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: fastapi-app
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: fastapi-app
  template:
    metadata:
      labels:
        app: fastapi-app
    spec:
      containers:
      - name: fastapi-app
        image: fastapi-health-app:latest
        imagePullPolicy: Always
        ports:
        - containerPort: 8000

        livenessProbe:
          httpGet:
            path: /health
            port: 8000
          initialDelaySeconds: 5
          periodSeconds: 10
          timeoutSeconds: 1
          failureThreshold: 3

        readinessProbe:
          httpGet:
            path: /health
            port: 8000
          initialDelaySeconds: 5
          periodSeconds: 5
          timeoutSeconds: 1
          failureThreshold: 1

With this configuration, both liveness and rediness probes use HTTP GET requests to the path /health on port 8000.

The initialDelaySeconds option gives the app time to start before the first health check.

For liveness, the periodSeconds option sets the check interval to 10 seconds.
The failureThreshold option will restart the pod after 3 consecutive failed checks.

For readiness, the periodSeconds option sets the check interval to 5 seconds.
The failureThreshold option will mark the pod as not ready and remove it from service load balancers after one failed check.

To expose the app you need to create a service. Here's a simple service manifest:

apiVersion: v1
kind: Service
metadata:
  name: fastapi-app-service
spec:
  selector:
    app: fastapi-app
  ports:
  - port: 80
    targetPort: 8000
  type: ClusterIP

Applying the configuration

Once you've created both manifests, you should deploy them to your cluster.

kubectl apply -f deployment.yaml
kubectl apply -f service.yaml

Wait a few seconds for the pods to start, then you can check the status with:

kubectl get pods

NAME                                 READY   STATUS    RESTARTS   AGE
fastapi-app-86b64cbbd5-9qkvd         1/1     Running   0          5m

You should see the pod in a Running state with READY 1/1 once the readiness probe passes, meaning your app is ready to start receiving requests.

Verifying the probes work

To confirm the probes are working, you can check the pod details with:

kubectl describe pod [pod-name]

Look for the Liveness and Readiness sections in the output.

...
Liveness:  http-get http://:8000/health delay=5s timeout=1s period=10s #success=1 #failure=3
Readiness: http-get http://:8000/health delay=5s timeout=1s period=5s #success=1 #failure=1
...

If you port forward the service you can also test the endpoint locally:

kubectl port-forward svc/fastapi-app-service 8000:8000

You can use curl to see the endpoint response:

curl localhost:8000/health

In closing

Adding health endpoints to a FastAPI app takes only a few lines of code, and configuring Kubernetes probes is fairly easy.

The key difference is tunning the liveness and readiness probe options to your app needs.

If you want to extend this setup, you could add a different endpoint for readiness probe that verifies a database connection or a cache is available before marking the app as ready.

Switching a Zebra printer to Thermal Transfer Mode with ZPL

Sergio Peris — Fri, 17 Apr 2026 09:00:23 +0000

Zebra printers can be configured using ZPL commands; one of the main configurations is the Media Type, as printers can be either Thermal transfer or Direct thermal.

Thermal Transfer printers require a ribbon to print, while Direct Thermal printers require thermal labels.

Zebra printers use the ^MTa command to set the print method. We have the following options:

^MTT: Thermal Transfer
^MTD: Direct Thermal

To change the printer settings to Thermal Transfer, we must send the following ZPL commands:

^XA
^MTT
^XZ

This will change the media type of our printer for the current job.

If we want to persist this change between boots, we must save the settings using the ^JUS command.

So, the complete configuration will be:

^XA
^MTT
^JUS
^XZ

Configure static IP address on Netplan

Sergio Peris — Tue, 31 Mar 2026 09:00:23 +0000

I've recently set up a new Ubuntu Server 24.04 and needed to assign it a static IP address. For a server, you don't want the IP to change whenever DHCP leases expire.

Finding your network interface

Before making any configuration changes, you need to know the name of your network interface. On Ubuntu Server, you'll likely see something like ens33 or enp0s3.

Run this command to see all network interfaces:

ip link

Look for the interface that has an IP address assigned to it. That's the one you want to configure. In my case, it was enp0s3.

Configuring Netplan

Ubuntu Server 24.04 stores network configuration in /etc/netplan/. There's usually a file there called something like 50-cloud-init.yaml. Let's check what's in that directory:

ls /etc/netplan/

Open the configuration file and you will see something like this by default:

vi /etc/netplan/50-cloud-init.yaml

network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s3:
      dhcp4: true

Change it to use a static IP instead. Here's what I configured:

network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s3:
      dhcp4: false
      dhcp6: false
      addresses:
        - 192.168.1.100/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses:
          - 1.1.1.1
          - 1.0.0.1

As you can see, the IP address includes the CIDR notation. The CIDR /24 means a subnet mask of 255.255.255.0. I'm using explicit routes instead of the older gateway4 key, because Ubuntu 24.04 deprecated gateway4. For DNS, I pointed to Cloudflare's public DNS servers, but you can use the DNS servers of your choice.

Applying the changes

Once the file is saved, instruct Netplan to apply the changes:

sudo netplan apply

Verifying the changes

Check that your static IP is now assigned:

ip addr show enp0s3

It should now show your new static IP address.

Backup S3 buckets using rclone

Sergio Peris — Tue, 10 Feb 2026 08:00:24 +0000

Backing up our files is a crucial task that we don't consider until it's too late. Using rclone, we can make a backup of all our data stored in S3 buckets.

Installing rclone

First, we need to install rclone. We'll be using Ubuntu Server, but you can use any distribution supported.

curl https://rclone.org/install.sh | sudo bash

Once we've installed it, we can verify it.

rclone version

rclone v1.72.1
 - os/version: ubuntu 24.04 (64 bit)
 - os/kernel: 6.8.0-90-generic (x86_64)
 - os/type: linux
 - os/arch: amd64
 - go/version: go1.25.5
 - go/linking: static
 - go/tags: none

Configure the remote

To connect to our S3 storage, we must create a rclone remote.

rclone config

This command will prompt us to answer a few questions to configure it correctly.

Some options may differ from this example, so take your time reviewing the options offered to select the one that best suits your case.

n) New remote
name> s3-storage

Storage> s3
provider> Other
env_auth> false
access_key_id> ACCESS_ID_KEY
secret_access_key> ACCESS_SECRET_KEY
region> REGION
endpoint> http://s3.example.com
location_constraint>
acl> private
y/e/d> y
e/n/d/r/c/s/q> q

Test the remote

Once we've configured the remote, we need to test it. Running the following command should list all buckets available:

rclone lsd s3-storage:

-1 2026-01-29 21:09:35        -1 bucket-1
-1 2026-01-29 20:05:31        -1 bucket-2

Configuring the backup

To back up the S3 storage, we'll create a backup script.

vi /usr/local/bin/s3-backup.sh

#!/bin/bash
set -e

LOG="/var/log/rclone-backup.log"
DEST="/backup"

rclone sync garage: "$DEST" \
  --checksum \
  --fast-list \
  --s3-no-check-bucket \
  --transfers=8 \
  --checkers=16 \
  --log-file="$LOG" \
  --log-level INFO

This script will back up all S3 buckets to the /backup folder.

Next, we make the script executable.

chmod +x /usr/local/bin/s3-backup.sh

And run it to create the first backup.

s3-backup.sh

Set up a cron job

To run the backup periodically, we must create a cron job.

crontab -e

# Backup Garage S3 to QNAP daily at 02:00.
0 2 * * * /usr/local/bin/s3-backup.sh

This cron job will run the backup script every day at 02:00.

Add an NFS mount point to a Ubuntu Server

Sergio Peris — Mon, 02 Feb 2026 09:00:24 +0000

NFS allows us to mount a network share as a local device. This system uses the client IP address for authentication. Don't confuse it with SMB, which allows user and password authentication.

In this tutorial, we'll explain how to connect an NFS share to an Ubuntu Server as a client.

Install dependencies

First, we must install the dependencies.

apt install nfs-common

Create a mount point

Once we've installed the dependencies, we must ensure the mount point we want to use exists.

mount -p /mnt/backups

Add a persistent mount

Using the mount command, we can temporarily mount the NFS share. However, we'll modify the /etc/fstab file to make the mount persistent.

192.168.1.10:/Backups /mnt/backups nfs defaults,_netdev 0 0

To apply the changes we've made at /etc/fstab we must run:

mount -a

Now we can check that the NFS mount is working as expected.

df -h

Filesystem                     Size  Used Avail Use% Mounted on
/dev/sda2                       30G  6.9G   21G  25% /
192.168.1.10:/Backups          916G  594G  322G  65% /mnt/backups

Remove local and local-lvm from Proxmox

Sergio Peris — Mon, 26 Jan 2026 09:00:24 +0000

Proxmox, by default, configures two storage volumes on the disk where the Proxmox OS resides: one named local-lvm for storing the disk images and containers, and another named local for storing the ISO images, container templates, and backups.

The local-lvm, as its name suggests, is a LVM thin-provisioned.
The local is simply a directory stored at /var/lib/vz.

It's common to have more than one disk in a Proxmox host, so the best approach is to separate the Proxmox OS from the disk images. For example, a node with one 480GB disk for the Proxmox OS and two 960GB disks in RAID 0 for storing the disk images and containers.

To remove the local-lvm and local storage volumes, follow the steps below.

Using the Proxmox GUI, navigate to Datacenter > Storage.

There, select the local-lvm storage volume and remove it. Next, select the local storage volume and edit it to disable it, as this storage volume cannot be deleted.

Now, open a shell on your node, as you will run a few commands.

First, you should remove the logical volume:

lvremove /dev/pve/data

Next, you're going to reclaim the free space that is left unused in the logical volume:

lvresize -l +100%FREE /dev/pve/root

Finally, you must expand the disk format to be able to use the newly added space:

resize2fs /dev/mapper/pve-root

With these steps, you've successfully removed the local storage volumes from your Proxmox.

Registry CRUD actions on Windows Group Policy

Sergio Peris — Wed, 21 Jan 2026 09:00:24 +0000

Using Group Policies, you can modify the registry of all computers joined to the domain.

When you create a new GPO, one of the parameters you're required to configure is the action that will be performed. These are:

Create
Update
Replace
Delete

But do you know what each action entails?

Create action

This action will create the registry key if it doesn't exist. If it already exists, it will do nothing, even if the actual registry value doesn't match the value set in the GPO.

Update action

This is the default action. It updates the registry value to the one set in the GPO. If the registry key doesn't exist, it will also be created.

Replace action

This action will delete the registry key if it already exists and then recreate it. If it doesn't exist, it will be created. This is similar to the update action but more aggressive, because it will delete the registry key every time it is applied. This action is rarely used.

Delete action

This action will delete the registry key if it's present.

Now that you understand how each action works, you can begin configuring the GPO on your domain controller.

Disabling Fast Boot via Windows Registry

Sergio Peris — Mon, 19 Jan 2026 09:00:23 +0000

Fast Boot allows us to boot our computer faster by performing a deep hibernation instead of completely powering it off.

If you have startup scripts, you should disable Fast Boot because it will prevent running the scripts, as your computer will not be "starting up".

In a domain-controlled environment, you can set a Group Policy that disables Fast Boot for all your computers by modifying the Registry.

You should configure the following Registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Power\HiberbootEnable

With the value 0 as a DWORD.

With this Registry key, your computer will skip the Fast Boot and perform a complete power-off and startup cycle.

Trust any proxy in Laravel

Sergio Peris — Mon, 12 Jan 2026 09:00:23 +0000

It's a common practice to deploy Laravel apps behind load balancers, aka proxy.

But doing this requires you to change the middleware settings so Laravel trusts your load balancer.

If you don't change it, some side effects may occur, such as hitting rate limiters on for all users at once instead of per IP address.

In your bootstrap/app.php file, you need to add the following inside the ->withMiddleware function.

$middleware->trustProxies(at: '*')

The asterisk * will trust any load balancer.

Please note that it's recommended to narrow down the allowed proxies, because any user can tamper with the header used to determine the real user IP.

If you only have one load balancer and you know the IP address, you can set the IP address like this:

$middleware->trustProxies(at: '10.0.0.2')

If you have multiple load balancers, you can provide an array.

$middleware->trustProxies(at: [
  '10.0.0.2',
  '10.0.1.2',
])

Or even a CIDR for the IP addresses.

$middleware->trustProxies(at: '10.0.0.0/8')

In some cases, the load balancer adds its IP address to the right side of the X-Forwarded-For standard header, maintaining the leftmost IP address as the actual user IP.

To ensure Laravel obtains the correct IP address for the user's IP, you may need to set it to 0.0.0.0/0, allowing any load balancer to discard all IP addresses in this header except the leftmost one.

Trust proxy with Traefik in K8s

Sergio Peris — Mon, 05 Jan 2026 09:00:22 +0000

Traefik, by default, will not trust the standard Forwarding headers Load Balancers usually populate with the client and proxy IPs.

If your apps don’t need to know the user’s real IP, you don’t need to change any configuration.
However, if you want to use the X-Forwarded-For header, some changes are required.

In your Traefik’s yaml configuration, you need to add the following argument with all the IP CIDRs from your Load Balancers. For example, if your Load Balancer is at 10.0.0.3.

--entryPoints.web.forwardedHeaders.trustedIPs=10.0.0.3/32

If you use MicroK8s, the arguments are in the Traefik daemonset resource.

If you don’t know the Load Balancer IPs, you can use 0.0.0.0/0 to trust all IPs, but this is not recommended, as any user can fake this header to bypass security features, such as IP-based rate limiters.

Trusting all IPs at Traefik requires validating the X-Forwarded-For header inside the application.