Yes, there’s a bit of upfront setup involved but once that’s out of the way, day-to-day management becomes significantly less painful, especially for the workloads. The operator sits inside your cluster and keeps an eye on things, picking up on any Kubernetes resource changes and making sure your Tailscale network reflects those changes accordingly.

My use case is as follows: I’ve installed ArgoCD at home and want to access it through my Tailnet. In this blog, the example will focus on an Nginx pod, but the principle is exactly the same. We’re not making any changes whatsoever to the pods or deployments; only the Services matter.

Let me guide you through the configuration of the Tailscale Operator and see how convenient it is. You’ll love it, I swear!

Step 1: Set up an ACL policy

Before anything else, you’ll need to set up some new ACL policy rules in Tailscale, this allows any tailnet devices that the operator spins up to be identified as belonging to your Tailnet.

Login to your Tailscale admin section –> Access Controls –> Tags

Create the 2 tags:

You’ll need to define 2 tags: k8s-operator and k8s.
Make sure k8s-operator is set as an owner of k8s

If you open the JSON editor tab, the equivalent in JSON format should be this:

{
  "tagOwners": {
	"tag:k8s-operator": [],
	"tag:k8s": ["tag:k8s-operator"]
  }
}

Step 2: Create an OAuth client

Your operator needs an OAuth client to authenticate to your Tailnet and register new pods and services.

Navigate to the admin console’s Settings –> Trust credentials –> Add Credential :

Choose OAuth, give your auth key a name, click continue.

Give Read+Write permissions under the “Devices” section.

Deploy the Keys section and add Read+Write permissions to the Auth Keys parameters.

Select the tag:k8s-operator tag created earlier from the dropdown to ensure devices created by the operator will have the tag assigned.

Once you click “Generate credential”, a pop-up window displays the key. Make sure to copy it in a safe place as it won’t be shown again.

Step 3: Install the Operator on your Kubernetes cluster

• Add the helm repository

# Add the repository
$ helm repo add tailscale https://pkgs.tailscale.com/helmcharts

# Update your client’s package list
$ helm repo update

• Run the helm install command to install the tailscale-operator

$ helm upgrade --install tailscale-operator tailscale/tailscale-operator \
  --namespace=tailscale \
  --create-namespace \
  --set-string oauth.clientId=<oauth_client_id> \
  --set-string oauth.clientSecret=<oauth_client_secret> \
  --wait

Replace the <oauth_client_id> and <oauth_client_secret> placeholders with the actual values you copied down at the end of the previous step.

• After a few seconds, check that the operator’s pod is up:

rancher:~ # kubectl get pods -n tailscale
NAME                        READY   STATUS    RESTARTS       AGE
operator-7699b5555b-v6wgw   1/1     Running   20 (16h ago)   55d

• Log into your Tailscale account and you should see the operator as a machine:

Step 4: Expose your Kubernetes services easily

For the purpose of this article, we’ll keep things simple: we’re just going to walk through a basic example that exposes an nginx service in your tailnet.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:latest
          ports:
            - containerPort: 80

---

apiVersion: v1
kind: Service
metadata:
  name: nginx
  annotations:
    tailscale.com/expose: "true"
spec:
  selector:
    app: nginx
  ports:
    - port: 80
      targetPort: 80

Take a closer look at the Service part of the YAML file. The key element here is the tailscale.com/expose annotation, sitting under the service’s metadata.annotations field.

That single annotation is all it takes to automatically expose the service in your Tailnet.
Once you apply it to your cluster, the Tailscale Operator picks it up on its own and takes care of setting up the appropriate route behind the scenes.

Set it to “true” if you want to expose the service and to “false” if not, it’s that easy!

Log back into your Tailscale account, you should see the service as a new device and your nginx pod should be exposed and reachable via its Tailscale IP address !

That’s it.
From now on, whatever you deploy in your Kubernetes cluster, and as long as it has the right annotation, will be detected by the Tailscale operator and exposed to your tailnet.

Cool, no?

L’article Expose your Kubernetes pods to your Tailnet using Tailscale operator est apparu en premier sur dbi Blog.

I faced an issue today where one of my colleagues was struggling to remotely connect to a Windows server via RDP.

He was using the default Remote Desktop app that comes standard with Windows 11 and everytime he’d connect, the application would hang at login. Something between 2 to 4 minutes, until he could finally type his password and access his remote machine.

Even after checking our firewall rules inside out, tracing his connections, nothing obvious could be found.

The checks:

I then decided to run a bunch of tests:

• 1st test – Connection from a Mac:

I tried accessing the remote server from my Mac using “Windows App”, no issues at all. The connection to the remote host works like a charm.

• 2st test – Connection from an old laptop running Windows10:

We still had an old laptop running Windows10 in the office, I wanted to give it a try. There again, no issue. The connection is lightning fast.

Even chatGPT was about to give up, after suggesting in turn, to check:
– IPv6 timeout
– Disable auto-redirect of local devices (printers, drives, smart cards…)
– Reverse DNS lookup delay
– Kerberos delay
– Windows Defender
– Power throttling
– …

It turns out that none of these suggestions actually worked.

As I am writing this article, I am still not sure what the root cause is. For sure, it is the Windows Remote Desktop application that either waits for a timeout of some sort or another child process preventing Remote Desktop to initiate the connection in a timely manner.

I’d put my 2 cents on Windows Security having to do with the problem, but I can’t really prove it at this stage.

The Solution:

Just do not use Remote Desktop with Windows 11
I downloaded MobaXterm, opened a RDP connection to my remote host and it worked right away.

Yes, sometimes you just spend a lot of time trying to fix stuff… until you realize there isn’t much you can do about it.

L’article Overcoming RDP connection issues on Windows 11 est apparu en premier sur dbi Blog.

I’ve been using Tailscale to connect my personal devices for a while. I have it installed almost everywhere: on my laptop, my phone, my Synology NAS, etc. It is very convenient as it helps me connect to any device, from anywhere. Tailscale adds a virtual interface to your device and manages its own IP address (you’ll understand why this is important in a minute)

Tailscale automatically assigns a unique IP address to each device in your Tailscale network (known as a tailnet). This IP address is known as a Tailscale IP address and comes from the shared address space defined in RFC6598, known as Carrier-Grade NAT (CGNAT).
(source: https://tailscale.com/kb/1015/100.x-addresses)

Today, I’m taking it to the next level: I’d like to install Tailscale alongside one of my application pod and access the web interface my pod exposes, directly from my Tailscale network (aka Tailnet).

The challenge:

I’ve installed Tailscale on the VM hosting my Kubernetes cluster (it’s a 1 node cluster, just for playing). Cool, I can access the VM from any other device. However, what about the web app my pod provides? How can I access it from my Tailnet?

As mentioned before, Tailscale has its own IP addressing, using 100.x.y.z addresses : your devices are assigned an IP from this address space.

Moreover, the network interface Tailscale creates (tailscale0) is not a standard interface and Kubernetes cannot simply expose services through that interface as for any other NodePort. To do so, you need to deploy Tailscale in your Kubernetes cluster.

Let’s do that.

The options:

Tailscale offers several options to connect your cluster to your tailnet:

• Proxy: Tailscale proxies traffic to one of your Kubernetes services. Your tailnet devices can communicate with the service but not with any other Kubernetes resources. Tailscale users can reach the service using the proxy’s name.
• Sidecar: Tailscale runs as a sidecar next to a specific pod in your cluster. It lets you expose that pod on your tailnet without allowing access to any others. Tailscale users can connect to the pod using its name.
• Subnet router: A subnet router deployment exposes your entire cluster network in your tailnet. Your Tailscale devices can connect to any pod or service in your cluster, provided that applicable Kubernetes network policies and Tailscale access controls allow it.

My use-case is to expose a specific pod to my tailnet (my speedtest-tracker app frontend), the “sidecar” option is then enough for my need.
Let’s see how to configure that together.

I invite you to read my other blog about speedtest-tracker. This is the app we are going to work with today.
I’ve been using speedtest-tracker for a while, but the app is only available from within my local network for now. Let’s see how to adapt my app’s deployment definition to add the Tailscale sidecar container.

What we need:

1. An application (that’s my speedtest-tracker app that already exists)
2. To generate an auth key that will be used by the Tailscale service deployed into the cluster
3. A secret with this auth key value in my cluster, for my pod to authenticate to my Tailscale account.
4. A service account, role and role binding to configure RBAC for my deployment ( my pod will use this service account and RBAC permissions to interact with the cluster)
5. Finally, I will add the sidecar container running Tailscale alongside my speedtest-tracker app container

Generate an auth key

First, let’s generate the auth key from my Tailscale account web interface.
This is done under Settings –> Keys –> Generate auth key…

Fill out the form, and make the key reusable. Then configure the device this key applies to as ephemeral (so is your pod).
Copy the key value somewhere as we are going to need it in a moment.

Create a secret

I create my secret, here is my tailscale-secret.yaml file:

apiVersion: v1
kind: Secret
metadata:
  name: tailscale-auth
stringData:
  TS_AUTHKEY: <my key value from previous step>

I apply the configuration to my speedtest namespace:

kubectl apply -f tailscale-secret.yaml -n speedtest

Service account, role and role binding

Next step is to configure RBAC for my Tailscale deployment. I need a service account, a role and role binding. Lucky me, Tailscale doc is well written, all I need is to follow their instructions.

I create a manifest called tailscale-rbac.yaml:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: tailscale

---

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: tailscale
rules:
  - apiGroups: [""]
    resourceNames: ["tailscale-auth"]
    resources: ["secrets"]
    verbs: ["get", "update", "patch"]

---

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: tailscale
subjects:
  - kind: ServiceAccount
    name: tailscale
roleRef:
  kind: Role
  name: tailscale
  apiGroup: rbac.authorization.k8s.io

I apply the configuration to my speedtest namespace:

kubectl apply -f tailscale-rbac.yaml -n speedtest

Add the sidecar container to my deployment

Last step is to adapt my existing deployment to add the tailscale sidecar container.

Under the spec section, we need to assign the serviceAccount created previously, to the pod:

serviceAccountName: tailscale

Then I create the sidecar container as per the tailscale documentation

apiVersion: apps/v1
kind: Deployment
metadata:
  name: speedtest-tracker
spec:
  replicas: 1
  revisionHistoryLimit: 0
  selector:
    matchLabels:
      app: speedtest-tracker
  template:
    metadata:
      labels:
        app: speedtest-tracker
    spec:
      serviceAccountName: tailscale  ## <-- Add the Service Account Name
      containers:
        ##### Tailscal sidecar container definition#######
        - name: tailscale-sidecar
          image: ghcr.io/tailscale/tailscale:latest
          env:
            - name: TS_KUBE_SECRET
              value: tailscale-auth
            - name: TS_AUTHKEY
              valueFrom:
                secretKeyRef:
                  name: tailscale-auth
                  key: TS_AUTHKEY
            - name: TS_USERSPACE
              value: "false"
          securityContext:
            capabilities:
              add:
               - NET_ADMIN
        ######################

        - name: speedtest-tracker
          image: lscr.io/linuxserver/speedtest-tracker:latest
          ports:
            - containerPort: 80
          env:
            - name: PUID
              value: "1000"
            - name: PGID
              value: "1000"
            - name: DB_CONNECTION
              value: pgsql
            - name: DB_HOST
              value: postgres
            - name: DB_PORT
              value: "5432"
            - name: DB_DATABASE
              value: speedtest_tracker
            - name: DB_USERNAME
              value: speedy
            - name: DB_PASSWORD
              value: password

          volumeMounts:
            - mountPath: /config
              name: speedtest-tracker
      volumes:
        - name: speedtest-tracker
          persistentVolumeClaim:
            claimName: speedtest-tracker

I apply the configuration to my speedtest namespace:

kubectl apply -f speedtest-tracker.yaml -n speedtest

Quick check, my speedtest-tracker pod is now running with 2 containers inside:

Rancher:~/syno/speedtest # kubectl get pods -n speedtest
NAME                                READY   STATUS    RESTARTS   AGE
postgres-7958dd877c-f4d2l           1/1     Running   0          22h
speedtest-tracker-8975967cd-s2fmc   2/2     Running   0          105m

And that’s it!

I can now access my app from both networks : my local network and my tailnet.

My pod is now seen as a device in my Tailscale network and can communicate with my other machines.

Conclusion

What we’ve done is to turn our Pod into a Tailscale node by injecting a WireGuard interface into the Pod’s shared network namespace, with the help of a tailscale sidecar container. This allows encrypted traffic to flow directly to the app container without Kubernetes Services or Ingress.

This is it, I hope you enjoyed reading this blog and that you learned something new.

If so, drop a like, it’s always appreciated 😉

To go further, please visit the Tailscale official documentation that will take you through all the steps and options to configure your tailnet on Kubernetes:
https://tailscale.com/learn/managing-access-to-kubernetes-with-tailscale#sidecar-deployments

L’article Access your Kubernetes pods via Tailscale using a Sidecar container est apparu en premier sur dbi Blog.

It turns out that there is a project called Speedtest-tracker, written and maintained by Alex Justesen on GitHub that does just what I was looking for. Behind the scenes, speedtest-tracker uses the official Ookla CLI.

Speedtest Tracker is a self-hosted application that monitors the performance and uptime of your internet connection. Built using Laravel and Speedtest CLI from Ookla®, deployable with Docker.

The cool thing is that Speedtest Tracker is containerized; you can run it anywhere you want! At first, I had installed it as a Docker container on my Synology, but the NAS I own only has 1Gbps Ethernet ports, and my ISP advertises DL/UL speeds of 5 Gbps / 900 Mbps

I have a mini PC that I use for my YaK projects, which embeds a 2.5Gbps Ethernet card. I’d rather use this machine than the NAS. Even though I will not be able to test the full speed my ISP provides, at least I will be able to see if I get near 2.5Gbps, which is already a great download speed.

OK, enough talking, let’s get our hands dirty and let’s deploy Speedtest-tracker!

Your list of ingredients

Here is what you need to add to your recipe:

• A hypervisor, in my case I’m using Proxmox
• A virtual machine (on which I’m using SUSE Linux, but any distro will work just fine)
• A Kubernetes cluster. Keep it simple, install a single node RKE2
• A persistent volume: local-path provisioner does the job

I’m passing these steps here, but you can find them in my other blog dedicated to installing the YaK, if you need.

Everything is well documented on Speedtest tracker web page

There is already a community manifest available for Kubernetes, written and maintained by Maxime Moreillon.

How to install speedtest-tracker?

Installing speedtest tracker is as simple as deploying 2 yaml files:

• 1 for the postgreSQL database
• 1 for the frontend app

The PG database and the application manifests are available here.
All the credit goes to Maxime Moreillon, who wrote these manifests and made them available to the community.
All I had to do was save the files to my “speedtest” folder and adjust them to my context.

localhost:~ # cd speedtest
localhost:~/speedtest # ls -ltrh
total 8.0K
-rw-r--r-- 1 root root 1.1K Jul 29 16:29 postgres.yaml
-rw-r--r-- 1 root root 2.2K Aug  3 18:48 speedtest-tracker.yaml

My Postgres manifest

I haven’t changed a single line from Maxime Moreillon’s code. The manifest includes the PVC definition, the PostgreSQL deployment itself, and a service:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgres
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres
spec:
  replicas: 1
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
        - name: postgres
          image: postgres:15.1
          env:
            - name: POSTGRES_PASSWORD
              value: password
            - name: POSTGRES_DB
              value: speedtest_tracker
            - name: POSTGRES_USER
              value: speedy
          volumeMounts:
            - mountPath: /var/lib/postgresql/data
              name: postgres
      volumes:
        - name: postgres
          persistentVolumeClaim:
            claimName: postgres

---
apiVersion: v1
kind: Service
metadata:
  name: postgres
spec:
  ports:
    - port: 5432
  selector:
    app: postgres
  type: ClusterIP

My speedtest-tracker manifest

With a few adjustments from Maxime’s code to fit my needs. It comes with the PVC definition, the application deployment, and the service:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: speedtest-tracker
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: local-path  # Adjust if you're using a different StorageClass

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: speedtest-tracker
spec:
  replicas: 1
  revisionHistoryLimit: 0
  selector:
    matchLabels:
      app: speedtest-tracker
  template:
    metadata:
      labels:
        app: speedtest-tracker
    spec:
      containers:
        - name: speedtest-tracker
          image: lscr.io/linuxserver/speedtest-tracker:latest
          ports:
            - containerPort: 80
          env:
            - name: PUID
              value: "1000"
            - name: PGID
              value: "1000"
            - name: DB_CONNECTION
              value: pgsql
            - name: DB_HOST
              value: postgres
            - name: DB_PORT
              value: "5432"
            - name: DB_DATABASE
              value: speedtest_tracker
            - name: DB_USERNAME
              value: speedy
            - name: DB_PASSWORD
              value: password

########MY PERSONAL ENV VARIABLES########
            - name: APP_NAME
              value: home-speedtest-k8s
            - name: APP_KEY
              value: <generate your own app key>
            - name: DISPLAY_TIMEZONE
              value: Europe/Paris
            - name: SPEEDTEST_SERVERS
              value: "62493"
            - name: SPEEDTEST_SCHEDULE
              value: '*/30 * * * *'
            - name: PUBLIC_DASHBOARD
              value: "true"
#########################################

          volumeMounts:
            - mountPath: /config
              name: speedtest-tracker
      volumes:
        - name: speedtest-tracker
          persistentVolumeClaim:
            claimName: speedtest-tracker

---
apiVersion: v1
kind: Service
metadata:
  name: speedtest-tracker
  labels:
    app: speedtest-tracker
spec:
  selector:
    app: speedtest-tracker
  type: NodePort
  ports:
    - name: http
      port: 80
      targetPort: 80
      nodePort: 30080  # You can change this to any port in the 30000-32767 range

Now, generate your own APP KEY and paste the value in the placeholder in the code above (including the base64: prefix), here is how:

echo -n 'base64:'; openssl rand -base64 32;

And that’s it!
Once your manifests are ready and once you are happy with the environment variables you want (the list of env. variables is available here), you just need to create your namespace on your cluster and apply the configuration:

kubectl create ns speedtest
kubectl apply -f speedtest/postgres.yaml -n speedtest
kubectl apply -f speedtest/speedtest-racker.yaml -n speedtest

After a few seconds, your pods will come up:

localhost:~/speedtest # kubectl get pods -n speedtest
NAME                                 READY   STATUS    RESTARTS        AGE
postgres-6c8499b968-rbwlw            1/1     Running   2 (4d18h ago)   5d21h
speedtest-tracker-7997cbdc8f-64n7c   1/1     Running   0               19h

Enjoy !

If you did things right, you should be able to monitor your internet speed and display the results on a neat UI. In my case, I fire a speedtest every 30 minutes (I know, that’s overkill, but I just wanted to play a bit. I will reduce the frequency to something more reasonable, I promise )

Cool, no?

To go further

I’d love to monitor the full bandwidth my ISP advertises, but I’m limited by my hardware: my router does not support link aggregation, and it only comes with one 10G fiber-optic WAN interface + one 2.5 Gbps and two 1Gbps LAN interfaces. There is no chance I can test the full fiber-optic capacity with this hardware.

In the future, I might buy a switch that supports LACP and configure my router in bridge mode to be able to reach the full WAN bandwidth, or invest in a router that provides more high-speed interfaces. But to be honest, the investment is not really worth it.

One thing I could do however would be to enable HTTPS and add a Let’s Encrypt certificate to secure the connections to my frontend. That’s an improvement I could make soon.

L’article Monitor your ISP’s performance with Speedtest Tracker est apparu en premier sur dbi Blog.

The demo environment is not supposed to be used for production purpose (it’s just a demo and everything is scrubbed after 4 hours)
dbi services shall not be held liable for any data loss on this demo environment.

Wanna give it a try?

To do so, simply connect to https://yak4all.io/demo/, fill in the form and you will receive a confirmation email from no-reply@dbi-services.com.

Please allow 5 to 10 minutes for the environment to be provisioned and the YaK to spin up. Once up and running you’ll receive a second email from no-reply@demo.yak4all.io with the URL and credentials to connect to your YaK.

Check your inbox and junk mail to make sure you don’t miss out on your YaK experience!

Limitations

The demo environment we provision comes with the following restrictions (this will not be the case with a regular installation of YaK):

• AWS infrastructure:
  • Available shapes: t3.micro, t3.small, t3.medium
  • Available disk types: gp2, gp3
  • Disk sizes: max 50gb
  • Available component: PostgreSQL
  • AWS Region: eu-west-1

• Azure infrastructure:
  • Available shapes: Standard_B2s, Standard_B2ms
  • Available disk types: Standard_LRS, StandardSSD_LRS
  • Disk sizes: max 64gb
  • Available component: PostgreSQL

YaK Login Page

Open the link received and log into the YaK with the credentials from the email.

Where to start?

Alright, you’re all set, your environment is ready. Let’s give it a try!

We have pre-provisioned the YaK with a few things for you so that you can almost immediately deploy your servers and components:

• 2 infrastructures have been pre-provisioned:
  • An AWS demo infrastructure: “aws-demo-1”
  • A Microsoft Azure demo infrastructure: “azure-demo-1”
• Cloud providers secrets have been attached to these infrastructures
• A PostgreSQL component type is available to you

What you need to do now

Well, we’ve thought of a scenario, but feel free to explore the YaK on your own if you prefer.

Our use case here is to deploy a server to AWS or to Azure and then deploy a PostgreSQL database instance on it.

1. Declare a SSH key

In order to connect securely to the Linux servers once created, a pair of SSH keys must be generated and the private key must be transferred to the servers.

• Generate your SSH key:

SSH keys can be generated from any Linux-based machine running openSSH with the “ssh-keygen” command.

$ ssh-keygen -b 4096 -m PEM -t rsa -f my-ssh-key -q -N ""

Windows users can generate SSH keys using the PuTTYgen utility (follow this link)

• Copy the content of the private key file:

$ cat my-ssh-key
##This is just an example, generate your own private key

-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAACmFlczI1Ni1jdHIAAAAGYmNyeXB0AAAAGAAAABASDILVb1
MiZ78g848c6Dk6KYwkJZXloSIruLe+Sid0Xd+Lb1rAxbwzAhXWRMzzBT5k3WciXk2fMhUD
p4YSahpYvquZK950aXiZNDOJpKZP8wjf4g4nQyiJZ/0G0J9mIaI2h/fr8TA67KHYtu/Eyf
PN9bKJwII3aiGlu5/Viq2cgYT8jJ01AK8cY3tSqKdlrN2GyxllBFl42QplbxA2USPJ1E6v
VIjtbmJjdz[...........................................]qAc4HxP02t/N2ZN
q+dDNWeShfVz4zjApPQCzdiGqLAlzUy67KNxQgljhaOEaYTQgrLE8XNGsIFNZwGvsEo/xZ
XnN2p
-----END OPENSSH PRIVATE KEY-----

1. Feed the YaK with the SSH key:
   • From the menu, navigate to Configuration -> Secrets
   • Click “Declare“
   • Give a name to your secret (my-ssh-key)
   • Select “ssh key” as secret type
2. Paste the entirety of the private key previously copied, into the corresponding field of the form
3. Click “Save“

2. Attach your SSH key to the infrastructure

1. From the menu, navigate to “Infrastructures“
2. Select the infrastructure you would like to deploy to in the list (“aws-demo-1” or “azure-demo-1”)
3. Click the “Action” button
4. Click “Attach secret“
5. Select the SSH secret created in the previous step from the list
6. Click “Attach“

3. Declare a server

1. Navigate to the “Servers” menu
2. Click “Declare“
3. Give it a name
4. Select the Infrastructure to deploy your server to (“aws-demo-1” or “azure-demo-1”)
5. Select an Image to install : let’s take Debian 12 for example
6. Select a server Shape
7. Add custom tags as per your need (optional)
8. Network section:
   • Mode: automatic
   • IP: leave blank
   • Scope: public
   • Tick the “Admin access” checkbox: this defines the IP address used to connect to the server for configuration purpose.
9. Click Save

In Azure, VM names must be unique. Since we’re all sharing the same demo environment, avoid instance names that are too obvious and could conflict with other users’ machines, such as “srv01”, ‘server1’, “myserver”, etc. Be creative to avoid potential conflicts with other users

4. Deploy your server

1. Select your server in the list
2. Click “Deploy” from the “Actions” menu
3. Confirm “Deploy” in the pop up box
   • Follow the deployment steps from the Jobs menu to see what the YaK is doing behind the scene. If you’ve followed the steps it should succeed (if not you must have missed something )
4. Wait until the job status is “Successful”
5. Your server should be started automatically and will soon be in a “running” state
   • You should already be able to connect to it via SSH by selecting the server and retrieving the public IP from the server parameters. (see step “7. Connect to your server”)
   • But hold your horses! Let’s deploy a component on it! (if you can’t wait, skip the component deployment and come back to it later, that’s OK)

5. Declare your component

1. Navigate to the “Components” menu
2. Click “Declare“
3. Give it a name (ex: PG01)
4. Select your component type (postgresql_instance)
5. Select your subcomponent type (standalone)
   • HA requires 3 servers be deployed, in this example we will consider a standalone setup as we have declared 1 server only
6. Choose your Provider (here it will be aws or azure)
7. Select the PostgreSQL host where you want to deploy your database instance (the server created previously)
8. Fill in the “Instance name” field (ex: mypgdb)
9. Navigate to the “Storage” tab and fill in the required fields.
   • Set Max size of component disks for the 3 file systems:
     • /u01 -> 40GB
     • /u02 -> 20GB
     • /u90 -> 20GB
10. Click “Save“

6. Deploy your component

Your PostgreSQL database instance is configured, now let’s deploy it:

1. Select the component you’ve just configured from the list
2. Click “Actions“
3. Then click “Deploy a new PostgreSQL Standalone instance”
4. Confirm your choice in the pop-up menu
5. Seat back, relax, follow the deployment steps from the jobs menu and wait until your component is successfully installed and configured.

7. Connect to your server and play around

• Open a SSH connection to the public IP address of your server:

DEMOUSER@demo$ ssh -i my-ssh-key <user>@<PUBLIC_IP>

• Your PUBLIC_IP address can be retrieved from Servers -> Parameters
• User:
  • Azure default user is azureuser
  • AWS default users (see AWS doc for more details):
    • The default user for debian based AMI is “admin“, but this could be something else, based on the AMI you selected.
    • For an Amazon Linux AMI, the username is ec2-user.
    • For a CentOS AMI, the username is centos or ec2-user.
      • For a Debian AMI, the username is admin.
      • For a Fedora AMI, the username is fedora or ec2-user.
      • For a RHEL AMI, the username is ec2-user or root.
      • For a SUSE AMI, the username is ec2-user or root.
      • For an Ubuntu AMI, the username is ubuntu.
      • For an Oracle AMI, the username is ec2-user.
      • For a Bitnami AMI, the username is bitnami.

• Play with your PostgreSQL database instance!

admin@my-server1:~$ sudo su - postgres


 PostgreSQL Clusters up and running on this host:
 ----------------------------------------------------------------------------------------------
    mypgdb      ->  /u02/pgdata/17/mypgdb                                    ->  5432  ==> OPEN

 PostgreSQL Clusters NOT running on this host:
 ----------------------------------------------------------------------------------------------

16:39:13 postgres@my-server1:/home/postgres/ [pg17.2] psql -p 5432
psql (17.2 dbi services build)
Type "help" for help.

postgres=#

Thanks for reading this blog, for more info about the YaK, visit yak4all.io or contact us directly.

Read my other blog if you’d like to install your own RKE2 Kubernetes cluster and your own YaK at home!

Happy YaKing !

L’article Try YaK for free with YaK Demo est apparu en premier sur dbi Blog.

Let’s dive-in.

In this article, I will explain how I installed a single node Kubernetes cluster with SUSE RKE2 and deployed my own local YaK instance.

Here is my setup:

• Intel NUC 13 Pro (with Intel Core i5-1340P)
• 64GB of RAM DDR4
• 1TB SSD

I’m using Proxmox as a virtualisation platform on this mini PC, and I’ve chosen SUSE Leap 15.6 as the operating system for the virtual machine that will host my RKE2 installation.

Create my VM in Proxmox

First, I created a VM and dedicated some resources to my instance.

SUSE recommends at least 8GB of RAM and 4vCPU for RKE2 to run smoothly.

Let’s start with that, I can adjust later if the system struggles.

I added 50GB of storage, that should be more than enough (that’s a lot of storage, we really don’t need that much for the YaK itself, but I might reuse this VM for other purposes too)

I’m passing the installation steps of SUSE Leap in server mode, as they are straightforward.
But, just in case, I’m adding the links to Proxmox and to SUSE Leap install docs here.

Install packages

First of all, we need to install the following packages on the VM hosting the YaK:

• Tar
• Git
• Helm

Let’s check what is already installed by default with SUSE Leap 15.6:

localhost:~ # zypper se --installed-only tar
Loading repository data...
Reading installed packages...

S  | Name                    | Summary                                          | Type
---+-------------------------+--------------------------------------------------+--------
i  | cantarell-fonts         | Contemporary Humanist Sans Serif Font            | package
i  | deltarpm                | Tools to Create and Apply deltarpms              | package
i  | shared-python-startup   | Startup script shared by all Python interpreters | package
i  | star                    | POSIX.1-2001-Compliant Tar Implementation        | package
i  | star-rmt                | Magnetic tape control and server                 | package
i  | tar                     | GNU implementation of ((t)ape (ar)chiver)        | package
i  | tar-lang                | Translations for package tar                     | package
i  | tar-rmt                 | Remote tape drive control server by GNU          | package
i  | zypper-needs-restarting | needs-restarting compatibility with zypper       | package

localhost:~ # zypper se --installed-only git
Loading repository data...
Reading installed packages...
No matching items found.

localhost:~ # zypper se --installed-only helm
Loading repository data...
Reading installed packages...
No matching items found.

As you can see, Tar is already installed but not Git nor Helm. Let’s install them:

localhost:~ # zypper install git
localhost:~ # zypper install helm

Stop firewalld

As a pre-requisite, Firewalld must be stopped.
Let’s check its status:

localhost:~ # systemctl status firewalld
● firewalld.service - firewalld - dynamic firewall daemon
     Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; preset: disabled)
     Active: active (running) since Wed 2025-04-30 12:12:43 CEST; 2h 7min ago
       Docs: man:firewalld(1)
   Main PID: 743 (firewalld)
      Tasks: 2 (limit: 4915)
        CPU: 349ms
     CGroup: /system.slice/firewalld.service
             └─743 /usr/bin/python3 /usr/sbin/firewalld --nofork --nopid

Apr 30 12:12:43 localhost systemd[1]: Starting firewalld - dynamic firewall daemon...
Apr 30 12:12:43 localhost systemd[1]: Started firewalld - dynamic firewall daemon.

Firewalld is active. I need to stop and disable the service so that it does not restart at system startup:

localhost:~ # systemctl stop firewalld
localhost:~ # systemctl disable firewalld

Install RKE2

Next, I installed RKE2. To do so, I simply followed the official procedure: https://docs.rke2.io/install/quickstart

localhost:~ # curl -sfL https://get.rke2.io | sh -
localhost:~ # systemctl enable rke2-server.service
localhost:~ # systemctl start rke2-server.service

As mentioned in the RKE2 documentation: “additional utilities will be installed at /var/lib/rancher/rke2/bin/. They include: kubectl, crictl, and ctr.
Note that these are not on your path by default.”

I’m adding the repository to my default PATH (this step can be done temporarily or permanently, by editing your ~/.bashrc file). I chose to make it permanent by editing my ~/.bashrc file, but it’s up to you.

export PATH="/var/lib/rancher/rke2/bin:$PATH"

RKE2 install writes a kubeconfig file to /etc/rancher/rke2/rke2.yaml.
Again, I’m adding this into my ~/.bashrc file

export KUBECONFIG=/etc/rancher/rke2/rke2.yaml

I check that the Kubernetes cluster is up and pods are running:

localhost:~ # kubectl get nodes
NAME        STATUS   ROLES                       AGE   VERSION
localhost   Ready    control-plane,etcd,master   22m   v1.31.7+rke2r1

localhost:~ # kubectl get pods -A
NAMESPACE     NAME                                                    READY   STATUS      RESTARTS      AGE
kube-system   cloud-controller-manager-localhost                      1/1     Running     1 (23m ago)   22m
kube-system   etcd-localhost                                          1/1     Running     0             22m
kube-system   helm-install-rke2-canal-nxphw                           0/1     Completed   0             23m
kube-system   helm-install-rke2-coredns-2whps                         0/1     Completed   0             23m
kube-system   helm-install-rke2-ingress-nginx-9mpwb                   0/1     Completed   0             23m
kube-system   helm-install-rke2-metrics-server-t8g27                  0/1     Completed   0             23m
kube-system   helm-install-rke2-runtimeclasses-nbq2v                  0/1     Completed   0             23m
kube-system   helm-install-rke2-snapshot-controller-crd-fmwqh         0/1     Completed   0             23m
kube-system   helm-install-rke2-snapshot-controller-nqq5g             0/1     Completed   1             23m
kube-system   kube-apiserver-localhost                                1/1     Running     0             22m
kube-system   kube-controller-manager-localhost                       1/1     Running     0             22m
kube-system   kube-proxy-localhost                                    1/1     Running     0             22m
kube-system   kube-scheduler-localhost                                1/1     Running     0             22m
kube-system   rke2-canal-qlk8b                                        2/2     Running     0             22m
kube-system   rke2-coredns-rke2-coredns-autoscaler-596dcdf688-dsjjz   1/1     Running     0             22m
kube-system   rke2-coredns-rke2-coredns-cf7df985b-zqwqn               1/1     Running     0             22m
kube-system   rke2-ingress-nginx-controller-b52nh                     1/1     Running     0             21m
kube-system   rke2-metrics-server-58ff89f9c7-dndfb                    0/1     Running     0             21m
kube-system   rke2-snapshot-controller-58dbcfd956-srw5z               1/1     Running     0             21m

Add a persistent volume

We need some storage, don’t we?
By default, RKE2 does not provide persistent volumes.
However, “Local Path Provisioner” provides a way for the Kubernetes users to utilize the local storage in each node (https://github.com/rancher/local-path-provisioner). Let’s use that.

localhost:~ # kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/v0.0.31/deploy/local-path-storage.yaml
namespace/local-path-storage created
serviceaccount/local-path-provisioner-service-account created
role.rbac.authorization.k8s.io/local-path-provisioner-role created
clusterrole.rbac.authorization.k8s.io/local-path-provisioner-role created
rolebinding.rbac.authorization.k8s.io/local-path-provisioner-bind created
clusterrolebinding.rbac.authorization.k8s.io/local-path-provisioner-bind created
deployment.apps/local-path-provisioner created
storageclass.storage.k8s.io/local-path created
configmap/local-path-config created

Install YaK

Alright, I now have a fully functional Kubernetes cluster.
Let’s install the YaK on it now.

• Create a namespace:

kubectl create ns yak

• Add yak repo

helm repo add yak https://gitlab.com/api/v4/projects/63133284/packages/helm/stable && helm repo update

• Create the yak.values.yaml definition file

localhost:~ # vi yak.values.yaml

global:
  hostname: yak.lab
  admin_credentials:
    password: "ABCdef1234@" #default password to be changed to your need

yak-postgres:
  postgresPassword: "" # Randomly generated if not set
  persistence:
    size: 20Gi
    storageClassName: "local-path" # Uses default if empty

yak-graphile:
  # Archive storage stores the component types archives at import time
  persistence: &archives_storage
    size: 20Gi
    storageClassName: "local-path" # Uses default if empty
  # If using a multi-node cluster, uncomment these 2 lines:
    #accessModes:
     # - ReadWriteMany

  # If you want to expose the rest API at https://hostname/data/graphql and have the postgraphile UI at https://yak.my-domain.local/data/graphiql
  ingress:
    enabled: true
    className: "" # Uses default if empty
    tls:
     - secretName: yak-tls-secret
       hosts:
       - yak.lab

yak-runner:
  image:
    pullPolicy: Always
  persistence:
  # Runner shares the archives storage with graphile
    graphile: *archives_storage
    components:
      enabled: true
      storageClassName: "local-path" # Uses default if empty
      size: 8Gi
    sshconfig:
      enabled: true
      storageClassName: "local-path" # Uses default if empty
      size: 1Gi

yak-ui:
  # Mandatory if you want to access the UI through ingress
  ingress:
    enabled: true
    className: "" # Uses default if empty
    tls:
     - secretName: yak-tls-secret
       hosts:
       - yak.lab

• Run Helm install YaK

helm install yak yak/yak -f yak.values.yaml -n yak

• Check that YaK is properly deployed (all 4 pods should be Running after a few minutes)

localhost:~ # kubectl get pods -n yak
NAME                            READY   STATUS    RESTARTS   AGE
yak-graphile-5b5454fd64-hmk2c   1/1     Running   0          1m
yak-postgres-7bcf4f9897-7mrdg   1/1     Running   0          1m
yak-runner-6669948599-9ggwn     1/1     Running   0          1m
yak-ui-7f6d77c765-spgfn         1/1     Running   0          1m

Connect to the YaK with https

Finally, let’s connect to our web app!

• Update your local /etc/hosts file and add your YaK server, in my case:

192.168.10.185   yak.lab

• Open a web browser and navigate to your URL : https://yak.lab
  • Default credentials :
    • User: admin
    • Password: ABCdef1234@

Voilà!!

I’ve now got a local YaK on RKE2 running at home, ready to deploy infrastructures, servers and components wherever I want.

For more info about the YaK, visit yak4all.io

And if you can’t be bothered installing your own YaK, you can bring up a fully functional YaK demo environment, within minutes : yak4all.io/demo
Feel free to play around and explore our use cases

Happy YaKing 😉 !

L’article Install a single node Kubernetes cluster with SUSE RKE2 and deploy your own YaK instance est apparu en premier sur dbi Blog.

Today is my first day at the KubeCon 2025 in London. It’s 8 AM, I’m in the lobby of my hotel and I can already hear “HAProxy”, “NGINX”, “Pipeline”, and “Kubernetes” here and there. There is no doubt, I am at the right place.

When I walked to the Excel London, I didn’t know what to expect. The place is just huge. The day has not started, and I already know I should have grabbed another pair of shoes.

To give you an idea, they expect between 12 and 15 thousand people….
I’m starting to realize this event is a one-of-a-kind.

Opening session in the Auditorium, my first thought was: how are they gonna fit all these people in?
Well, the Linux Foundation organizers seem to know what they are doing…
Drum rolls, lights shade, this is not just another IT people gathering, it’s a freaking show.

The tone is set, a few welcome words from the CNCF representatives and we are already talking about LLM. This is not a surprise; Artificial Intelligence is everywhere in this Kubecon.

Christin Yen, CEO and cofounder at Honeycomb tells us about observability and the impact of application development on users. How can AI help improve user experience by monitoring response time and analyzing tons of metadata.

Followed by Vijay Samuel, Architect at Ebay enlightening us on how they are making use of AI and LLM: human comprehension is limited, and the systems we manage have become so complex and so big that sorting of logs is impossible without the help of machine learning to attach a root cause to an alert.

Andrew Randall reminds us how awesome Kubernetes is but also how intimidating it can be for novice users. There is no such thing as a simple “apt-get install kubernetes” command: willing to install a Vanilla Kubernetes? You’d have to figure it out yourself, it’s a steep learning curve before you can even deploy your first cluster.
Based on this observation and willingness to reduce the impact on developers’ productivity, Microsoft has announced a new project called Headlamp, designed to make Kubernetes easier to use and, above all, easier to adopt. It comes with an in-cluster web portal (a k8s dashboard), a unified UI for multiple remote clusters, and a “Kubernetes Desktop”.
Pretty much like what our SUSE friends have accomplished with the great SUSE Rancher ;-). Let’s see!

Greg Kroah-Hartmann (Linux maintainer, Linux Foundation) attended to discuss the Linux Kernel and how they are integrating Rust and C into it.
Today’s Linux kernel contains 34 million lines of C, and about 25000 lines of Rust code.
Rust brings more safety as it allows the kernel to “crash safely” when an error occurs and makes the code more “maintainable”. Rust can prevent a huge majority of security issues at build time, not at review time: code is simpler, reviewing is easier, fewer bugs, more fun!

Closing the keynote with a great use-case of AI, I loved it because it really demonstrated how technology can improve people’s lives and I truly believe this is what technology should be about: moving science forward, promoting education, and closing the gap between our societies. Indeed, Rob Koch from Slalom explained how AI, combined with Kubernetes, is revolutionizing the world of deaf people with AI-driven sign language interpretation and recognition.
He explained the challenges they’re facing as it is overly complicated for a machine to capture the movement of a hand when hand-signing.
Making the difference between a “P” and a “Q” is a good example of this complexity as these 2 signs are very similar in sign language and capturing the right sign highly depends on the camera’s angle of view: perspective and scaling are important. AI models need a phenomenal amount of authentic data and scenarios to be trained. Moreover, machines need to “understand” the context of the conversation, not only words.
Kubernetes is ideal for that as it provides scaling capabilities, resource optimization for video processing, and task repeatability.

End of the keynote, it’s time for me to wander the corridors of the KubeCon and visit the booths.
All the big tech players are there of course…. but dozens of open source projects that we use daily within our infrastructures are represented and have a booth. It’s great to see that Open Source solutions are everywhere and everybody’s using them. I feel like a kid in a candy shop!

Alright, let’s “get some swag”. There are enough tee shirts, stickers, and other cool gadgets at this KubeCon for me to fill a massive suitcase, but I will try to be reasonable. Everyone has something to propose: hats, backpacks, tote bags, stickers, keyrings, lego sets. It’s too tempting, let’s see how long I can refrain from taking it all.

Visiting the RedHat stand:
I met with Stevan Le Meur, a developer at RedHat and we had a great exchange on what RedHat does with regards to Kubernetes. Stevan specializes in bootable containers and invited me to take a closer look at what bootc and podman can achieve.
The occasion for me to talk about our YaK project. Why not consider bootable containers with the YaK in a future release?
That’s clearly a topic we can discuss during our next roadmap meeting, let’s see if we add it to the list of upcoming features…

Walking down the hallway, I passed by the Linux Foundation booth where the topic being discussed was the certification exams.
For those interested in the CKA (Certified Kubernetes Administrator) exam, know that a new version has just been released.
This new version is a bit more difficult than the previous one, the passing score is still 66% and the format has not changed: it is still a proctored hands-on lab exam.

Good resources to practice before the exam: killer.sh (https://killer.sh/) , and the great environments and training material provided by KodeKloud (https://kodekloud.com/)

That’s enough reading for today.

L’article My journey to KubeCon 2025 est apparu en premier sur dbi Blog.

Hello, dear tech enthusiasts and cloud aficionados!

We’ve got some news that’s about to make your life —or your deployments, at least— a whole lot easier. Meet YaK 2.0, the latest game-changer in the world of automated multi-cloud PaaS deployment. After months of development, testing, troubleshooting, a fair share of meetings and way too much coffee, YaK is officially launching today.

Automated multi-cloud PaaS deployment. What’s the deal with YaK 2.0?

Because we believe IT professionals should spend time on complex, value-added tasks, but not on repetitive setups, we have decided to develop the YaK.
YaK is a framework that allows anyone to deploy any type of component on any platform, while ensuring quality, cost efficiency and reducing deployment time.

YaK 2.0 is your new best friend when it comes to deploying infrastructure that’s not just efficient but also identical across every platform you’re working with – be it multi-cloud or on-premises. Originating from the need to deploy multi-technology infrastructures quickly and effortlessly, YaK ensures your setup is consistent, whether you’re working with AWS, Azure, Oracle Cloud, or your own on-prem servers.

In simpler terms, YaK makes sure your deployment process is consistent and reliable, no matter where. Whether you’re scaling in the cloud or handling things in-house, YaK’s got your back.

Why you should have a look at YaK 2.0?

Here’s why we think YaK is going to become your favorite pet:

• Flexibility: Deploy across AWS, Azure, OCI, or your own servers—YaK adapts to your infrastructure, making every platform feel like home.
• Automation: Eliminate repetitive setups with automated deployments, saving you time and headaches.
• Cost efficiency & speed: YaK cuts time-to-market, streamlining deployments for fast, standardized rollouts that are both cost-effective and secure.
• Freedom from vendor lock-In: YaK is vendor-neutral, letting you deploy on your terms, across any environment.
• Swiss software backed up by a consulting company (dbi services) with extensive expertise in deployments.

With this release, we’re excited to announce a major upgrade:

• Sleek new user interface: YaK 2.0 now comes with a user-friendly interface, making it easier than ever to manage your deployments. Say hello to intuitive navigation.

• Components: We’ve got components on our roadmap (available with an annual subscription), and we’ll be announcing them shortly : Oracle Database, PostgreSQL, MongoDB, and Kubernetes are already on the list and will be released soon.

Many more will follow… Stay tuned!

How does it work?

YaK Core is the open-source part and is the heart of our product, featuring Ansible playbooks and a custom plugin that provides a single inventory for all platforms, making your server deployments seamless across clouds like AWS, Azure, and OCI.
If you want to see for yourself, our GitLab project is available here!

YaK Components are the value-added part of the product and bring you expert-designed modules for deploying databases and application servers, with an annual subscription to dbi services.

Join the YaK pack

Explore the power of automated multi-cloud PaaS deployment with YaK 2.0 and experience a new level of efficiency and flexibility. We can’t wait for you to try it out and see just how much it can streamline your deployment process. Whether you’re a startup with big dreams or an established enterprise looking to optimize, YaK is here to make your life easier.

Our YaK deserved its own web page, check it out for more information, to contact us or to try it out (free demo environments will be available soon): yak4all.io

Wanna ride the YaK? Check out our user documentation to get started!
We promise it’ll be the smoothest ride you’ve had in a while.

We’re not just launching a product; we’re building a community. We’d love for you to chime in, share your experiences, and help us make YaK even better. Follow us on LinkedIn, join our community on GitLab, and let’s create something amazing together.

Feel free to reach out to us for more details or for a live presentation: info@dbi-services.com

Thanks for being part of this exciting journey. We can’t wait to see what you build with YaK.

The YaK Team

—

P.S. If you’re wondering about the name, well, yaks are known for being hardy, reliable, and able to thrive in any environment. Plus, they look pretty cool, don’t you think?

L’article Introducing YaK 2.0: The future of effortless PaaS deployments across Clouds and On-Premises est apparu en premier sur dbi Blog.