Forem: Sergio Peris

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.

MicroK8s upgrade ingress from NGINX to Traefik

Sergio Peris — Mon, 29 Dec 2025 09:00:25 +0000

The Kubernetes nginx-ingress is scheduled to be retired in March 2026, so Canonical’s MicroK8s team replaced Nginx with Traefik for its ingress addon.

If you’re running a MicroK8s cluster with the Nginx ingress, you may want to upgrade it.

First, you need to disable the ingress addon to remove the old Nginx ingress.

microk8s disable ingress

Then, you should update the core addons repository.

microk8s addons repo update core

Finally, you can enable the new Traefik ingress.

microk8s enable ingress

The Traefik ingress is compatible with your previous Nginx configuration, so all your sites and services should work fine.

Passing Laravel route to Maizzle button

Sergio Peris — Mon, 08 Dec 2025 09:00:26 +0000

Maizzle is a framework that helps us quickly build HTML emails with Tailwind CSS. We can integrate it into our Laravel project to create beautiful emails.

By default, Maizzle provides us with a button component which can be used as a CTA button in our emails, like:

<x-button href="https://maizzle.com" class="bg-slate-950 hover:bg-slate-800">Verify email</x-button>

In Laravel, it's common to use the helper route to create links to different routes of the project.

For a "Verify email" button like the previous, we might modify it to something like this:

<x-button href="route('auth.verify-email')" class="bg-slate-950 hover:bg-slate-800">Verify email</x-button>

If we generate the email with this code, Maizzle will output this:

<a href="route('dns-check.results', [$check->project, $check])"

As you can see, the URL will not work as it was placed without being interpreted.

We might try to add the curly brackets to allow the route helper to be interpreted:

<x-button href="{{ route('auth.verify-email') }}"

But Maizzle will generate this:

<a href="{{ route(&amp;#039;auth.verify-email&amp;#039;) }}"

Ok, that's not working, maybe we need to add @ to escape the content:

<x-button href="@{{ route('auth.verify-email') }}"

With these, Maizzle will generate:

<a href="{{ route(&#039;auth.verify-email&#039;]) }}"

As you can see, this is not working.

The solution is to escape the content within the button component, not outside.

So we will use the button as:

<x-button href="route('auth.verify-email')"

And the button.html component should be modified from:

<a attributes href="{{{ href }}}"

To this:

<a attributes href="@{{ {{{ href }}} }}"

If we try it again, Maizzle will generate this:

<a href="{{ route('auth.verify-email') }}"

Now, when we send the email from our Laravel app, the button will have the correct link.