Run and expose Kubernetes Pod based Application using Quadlet and Inlets
Ygal Blum & Valentin Rothberg
This tutorial is inspired by a previous post from Alex Ellis’s on running inlets with compose.
But instead of Compose, we want to show how to deploy inlets via Quadlet and make use of Podman’s Kubernetes capabilities. Hence, we are going to run a .kube file via Quadlet and Podman.
Quadlet is a new way of running containerized workloads in systemd with Podman.
Running Podman in systemd achieves a high degree of robustness and automation since systemd can take care of the lifecycle management and monitoring of the workloads.
More advanced features such as Podman auto updates and custom health-check actions make Quadlet a handy tool for modern Edge Computing.
Deploy the Inlets Server
When using inlets, users can provision the VMs acting as tunnel servers on various cloud providers.
The post, inspiring this one, showed how to deploy it on Linode while a newer post describes how it can be deployed on AWS.
Follow either posts, or deploy the tunnel server on any other provider.
The inlets documentation provides details and examples for various providers.
Whichever provider you choose, inletsctl will print two parameters you will need when deploying the local client:
IP - The external IP address of the Inlets tunnel server
Auth-token - Token the client must use when connecting to the server
Running GHost along with Inlets client
You can run Ghost on your local computer, a Raspberry Pi, or an additional EC2 instance.
The Inlets client depends on two secrets inlets-license and inlets-token.
However, because these secrets are consumed by a Kubernetes Pod, they also must take the form of a Kubernetes Secret
Inlets Token Secret
Use the following jinja template inlets-token-secret.yml.j2: