DEV Community: Jean Silga

How I built a cloud native platform from scratch

Jean Silga — Mon, 14 Sep 2026 13:44:38 +0000

If you read my previous post titled "My journey to master Kubernetes and Cloud Native", you already know I decided to effectively build a cloud native platform from scratch before taking the CNPE exam. This decision may be rooted in procrastination at its finest: setting an insanely high goal as a precondition to make sure you never reach it…

Bottom line: I decided to build a fully fledged cloud native platform from scratch. Here is how it unfolded.

I started by renting two Virtual Private Servers from Contabo, a German cloud provider. How did I choose the provider? I turned to AI for advice. It gave me five proposals. Contabo was second on the list. I visited their website. The prices were clearly displayed. The proposed services were cleanly explained. The ordering process was straightforward. I settled on them and moved ahead.

I bought two VPS to start with. One with an NVMe drive for the control plane, a second with an SSD for the worker node. Both VPS were up and running, reachable and ready to use within a few minutes. It was a pleasant buying experience.

Then I prepared the control plane to install Kubernetes. I created a dedicated admin account on each node and uploaded my SSH keys so I could log in without typing a password. I went to the official Kubernetes docs and scripted all prerequisites in a Bash file. Then, I wrote an Ansible playbook to run that script on the control plane.

Time for the big moment: kubeadm init.

A few minutes later, I had a Kubernetes control plane staring at me, waiting for a CNI to become ready. I installed Calico and the control plane transitioned to a ready state, waiting for its first worker node.

I raced ahead. I applied a slightly modified version of my init playbook script to the worker node (for instance, no kubectl needed on the worker node). Next, I ran the kubeadm join command. It took a few minutes for the worker node to initialize and join the control plane. And it did.

Now I was looking at a functioning Kubernetes cluster: a control plane and worker node. It felt good. Going from renting the machines to having the Kubernetes cluster up and running took less than an hour.

Before I went on my CNCF Kubernetes certification journey, I wouldn't have had the courage to even try something like that. I surprised myself. The knowledge I gained through that journey, and the confidence it brought, were starting to show in ways I hadn't anticipated. And I was just getting started.

I tore down and rebuilt the cluster many times while perfecting the Bash script I used to init the nodes. For instance, I initially forgot to give a custom hostname to the nodes and only noticed it when the cluster was already up and running. Changing the hostname of a running control plane node can be risky. As I was just getting started, I chose to play it safe. I reinitialized the VM and started over. As I had everything scripted, I was back in business in a matter of minutes.

Remember: my goal was to set up a fully fledged cloud native platform. The Kubernetes cluster was just the first building block, the foundation. Like any foundation, it was a prerequisite for the rest. Now I could install the other building blocks. I installed each one with a Helm chart. Here is the whole platform as it stands today. The rest of this post walks through it, one building block at a time.

Click to open at full size.

First stop once Kubernetes was up and running: a GitOps tool. As a Certified Argo Project Associate, my natural choice was ArgoCD. I created the Git repo structure in GitLab to host my Argo Apps manifests, then a deploy token for ArgoCD to authenticate with, then a Kubernetes secret carrying that token so ArgoCD could talk to GitLab on its own. I installed ArgoCD from its Helm chart and wrote the file that is the entry point of every later installation on the cluster: the App of Apps bootstrap. That bootstrap file is the seed. From then on, a Git commit is all it takes for ArgoCD to pick something up and install it in the cluster.

Any Kubernetes setup beyond a hello-world use case needs a storage virtualization tool. The basic hostPath and emptyDir volumes are unsuited to real usage. I settled on Longhorn as a storage orchestrator. Storage redundancy is a prerequisite for any sensible storage virtualization, and so I needed at least a second worker node to pair with the one I had. I kept the control plane out of it. I did not want it involved in storing data.

Overall, I found Longhorn easy to set up, with an attractive benefit/complexity ratio. I also turned on encryption at rest. Longhorn encrypts at the volume level with Linux dm-crypt/LUKS, and I hold the key myself.

For database provisioning, I went with the CloudNativePG operator. It let me create databases for each deployed application with little effort. All I needed to do was create a custom resource with the new database parameters and the operator took care of everything: creating the database, keeping it up, enforcing the desired replica count.

Then came the choice of how to expose services. I settled on using Gateway API over Ingress. Then I picked Istio as a Gateway API provider. I already wanted Istio as a service mesh, mostly for mTLS. Using it as a Gateway API was a bonus. Besides, the setup was straightforward.

The next question to solve was about the IP address the gateway was going to use. Using a static IP of a node was a non-starter for two reasons: first, that would mean the gateway would go down if the node did. And second, I did not want to expose the public IP address of any node of the cluster. I devised a two-step solution. First, I used the Kube-vip utility to set up a private Virtual IP Address that can be moved to any of the cluster nodes dynamically. That way, that VIP stays functional as long as there is a healthy node in the cluster. I assigned that VIP to the gateway. Second, I set up a proxy node outside the cluster to serve as the entry point. That node is powered by HAProxy and is part of the private network of the cluster. It receives the traffic from the internet and then forwards it to the gateway using the VIP.

Next, certificate management. Cert-manager was the obvious choice, and I went with it. My first use was to issue a local Certificate Authority for my internal URLs. The second was more interesting: I connected it to Let's Encrypt, and valid certificates for my public URLs are now generated on the fly. Renewal is also automatic. It took me a few tries, but I got it working.

Next, I needed a vault for secrets. I considered HashiCorp Vault, but eventually settled on OpenBao, an open source fork that appeared when HashiCorp changed its licensing terms. To get the secrets from OpenBao into the Kubernetes cluster, I used the External Secrets Operator.

Up next: Continuous Integration. The CNCF promotes Tekton for this, so I gave it a try. The tool is complex to set up. I struggled with it at the beginning. It took me some time just to understand how many components Tekton has and what each one does. I finally got it up and running. I was glad later that I stuck with it. It was worth the trouble. Now I needed to connect it with a source code repository to test it.

That's when I thought: Tekton runs entirely inside the Kubernetes cluster. It can pull source code from any Git repository and push artifacts to any registry. But what if it pulled the code from inside the cluster and pushed artifacts to a registry inside the cluster too? All CI traffic would stay inside the cluster.

I looked around and Gitea was a good fit: it is a Git server and a container registry in one, it is cloud native and light on resource consumption. Gitea it was.

Then came Identity and Access Management. I needed to settle on how to handle authentication and authorization. That one was easy. I have been working with Keycloak since 2019. No debate.

Observability was on my list too. I wanted to know, at any time, what was going on with anything I deployed, what experience users were having, and to be able to investigate quickly when something went wrong. I went for all three kinds of telemetry data: logs, metrics and traces. I settled on the full Grafana stack and instrumented my apps with OpenTelemetry auto-instrumentation to get traces. Prometheus holds the metrics. Loki and Tempo are the backends for logs and traces, with MinIO as the storage behind both.

This is pretty much it. It was quite a ride, instructive and enjoyable. One year ago, I wouldn't have had the courage to take on such a side project. One thing made it possible: the confidence I built through the CNCF certifications.

Once you build such a platform, the natural thing is to find something to deploy on it. As I wrote last time, I had a three-month period at the start of 2026 when I wasn't on a job. To keep track of how I was spending my days, I built an Excel file with a list of daily habits I wanted to hold: physical exercise, meaningful learning, digital restraint, sleep and wake-up hours, journaling, a walk outside, meditation, and so on. I started this file to have an accurate record of how my days were going, instead of relying on gut feeling.

Later, while I was building my cloud native platform, an idea started forming: what if I turned that Excel file into a real app, deployed it on my platform, and shared it with the world? The idea was sensible enough that I decided to give it a try. I had been longing to build an app for some time anyway.

Before, I had been hiding behind two excuses: building was expensive, and I couldn't come up with an idea I thought was worth the trouble. Both excuses were now a thing of the past, for two reasons. AI had significantly lowered the cost of building. And I had more than an idea: I had something tangible, an Excel file I used every day, and knew was worth the trouble.

And one extra motivation, the icing on the cake: a brand-new, fully fledged cloud native platform ready to host the app.

What comes next is a story for another day.

Klatos

That Excel file became Klatos: a habit tracker that turns small daily steps into a changed year. It is the first product from Vixoris, and it runs on the platform this post describes.

Learn more about Klatos →

Update, September 20, 2026. I have since published the configuration behind this platform as a public repository. It is a sanitized snapshot of the GitOps repository ArgoCD deploys from: the App of Apps bootstrap, the Helm values for every component, the Ansible playbooks and the kubeadm scripts, all in one place. Every secret, hostname and IP address is replaced with a placeholder, so it is a reference to read and adapt, not a distribution to deploy as is. If you would rather see how the pieces fit together than read about it: https://gitlab.com/jeansilga-public/cloud-native-platform

Vixoris — Structures that compound.

My journey to master Kubernetes and Cloud Native

Jean Silga — Sun, 06 Sep 2026 16:42:13 +0000

I failed my first kubernetes certification. 53%. I needed 66%. Then I paused for 4 months. Here is what happened.

I have been actively in contact with kubernetes since 2019.

At first, I found it very appealing, but it quickly became kind of daunting.

It is a combination of very compelling and efficient solutions to real life dev, ops and security related problems that have been diagnosed for years. But at the same time, there is a steep learning curve: so many moving parts, complex behaviors, a broad set of concepts and notions ranging from almost every aspect of IT, and almost endless possibilities.

One can have the impression to be at ease with kubernetes after learning the basic kubernetes building blocks. But without a strong grasp of kubernetes fundamentals, struggle and trouble await at almost every corner when confronted with a real life meaningful project.

That has been my experience for some time. At times, I felt intimidated and overwhelmed with all these moving parts, endless possibilities, and seemingly never ending mysteries that kept showing up.

I had a chance to work with a few people that seemed to have a deep understanding of Kubernetes. Many times, what they were pulling off left me in awe. It was like wizardry. I realized two things from these experiences. One: the gap I had to fill so I would be confident working with kubernetes and be proficient at it. The second thing I realized is that it was possible to be very good at Kubernetes, and that being very good at it was rewarding, and that reward was worth seeking.

So I decided to embark on a quest to become proficient at Kubernetes.

Turning to the CNCF

I turned to the CNCF to help me fulfill that quest. CNCF is known to be the GoTo body for a whole lot of open source projects. Kubernetes occupies a special place in the open-source ecosystem as it has asserted itself as the cornerstone of modern IT infrastructure. The CNCF plays a crucial dual role by first, making sure the technology continues to evolve to meet the needs of modern IT systems, and second, helping bridge the knowledge gap of IT professionals with top quality courses and certifications. The reputation of the CNCF makes it a highly regarded body and so it was a natural choice for me.

The decision to turn to the CNCF was not without apprehension. Their certifications are known to be tough and realistic. Many of them consist of a set of real life challenges that one must solve in 2 hours. But that was the very reason for my choice to go to them. I wanted to crack this kubernetes thing once and for all. And successfully solving enterprise grade use cases under pressure seems like a good way to go.

Shoot for the stars

Before going heads down, I took some time to define my goals and settle on a strategy to achieve it. I have always been fascinated by the Kubernetes administrator role so I wanted to be one. CKA then seemed like an obvious target. But I decided to set a higher goal. As the saying goes, "Shoot for the Stars, Aim for the Moon". I settled on achieving Kubestronaut status as my goal and kickstarted the process in May 2025.

Kubestronaut status has 5 required certifications: entry level KCNA and KCSA, and intermediary level CKAD, CKA, CKS. KCNA and KCSA are multiple choice exams. KCNA demonstrates a user's foundational knowledge and skills in Kubernetes and the wider cloud native ecosystem, while KCSA demonstrates a user's understanding of foundational knowledge and skills of security technologies in the cloud native ecosystem.

CKAD, CKA and CKS are performance-based tests. For any of these three, the candidate must connect to an exam simulator to solve a set of realistic scenarios in a 2 hour timeframe.

CKAD — Certified Kubernetes Application Developer: demonstrates the ability to deploy applications on Kubernetes.
CKA — Certified Kubernetes Administrator: demonstrates the ability to set up and administer the kubernetes cluster itself.
CKS — Certified Kubernetes Security specialist: demonstrates the ability to secure the Kubernetes cluster and its workloads.

I subscribed to thrive-one, the one year plan of CNCF that grants access to all CNCF courses. Then I started the learning journey with an introduction to linux, then container fundamentals.

KCNA and KCSA were easy enough for me as I have been around the cloud native and kubernetes ecosystem for some time already. I had also already worked on security related roles. I felt at home. Then for some reason, I was convinced that CCA (Cilium Certified Associate) was part of the requirement for achieving Kubestronaut status (it wasn't). So I took and passed that one too.

The first attempt, and a miss

After these initial uplifting successes, the logical next step would have been to tackle the CKAD. I have been deploying applications on kubernetes for some time and I was familiar with most of the concepts tested by this exam. And it was the easiest one out of the three. But I chose to go for the CKA instead. The calling was just too strong to ignore any longer.

After completing the learning path suggested in the CKA exam page, I decided to give it a shot. And missed. 53% score VS 66% required.

As soon as the exam ended, I knew it didn't go well. Too much pressure. I almost froze at the first question. During the first 15 minutes, I couldn't think, I didn't move. To make things worse, the terminal seemed to have an issue: whenever I tried to create a resource, I systematically got an "object already exists" error. I spent a fair amount of time trying to figure it out. I was disheartened to fail miserably to solve what I perceived as being a simple task. It was the worst start I could have thought of. I should have skipped the question, but for some reason, I didn't. And it was a bad choice not to skip: lack of judgment, misplaced stubbornness, you name it.

I wasn't surprised when the result came out. But it reinforced the daunting feeling I had about kubernetes. So I paused. For 4 months, I made no attempt to advance on this matter.

The comeback

Until late November 2025 when I decided to resume my quest. The trigger was the end of my consulting contract. I knew it would be more challenging than usual to log a contract. AI was here and was already disrupting the IT job market. Fewer job postings, lower rates, and more applicants. A negative cocktail for job applicants. So this time, I chose to focus first on capitalizing on my SRE and security experiences by taking the SRE and security related exams first. Also, in the meantime, I followed some Golden Kubestronauts on LinkedIn. Their stories about their journey, the satisfaction and pride associated with Golden Kubestronaut status were contagious. So I decided to revise my own goal. Kubestronaut status did not seem high enough to make me land on CKA. I needed to shoot for Golden Kubestronaut status. So I went for it.

By the end of 2025, I landed two more exams: CGOA and PCA. I started 2026 by tackling the KCA exam that I earned in mid January. Then the calling came back again. I couldn't stop thinking about CKA! So I decided to give it another shot. But this time, I chose to increase my odds by subscribing to a kodekloud Pro plan at kodekloud.com. It turned out to be a good move.

kodekloud got many things right when it comes to learning kubernetes: focused and practical courses, hands-on labs with concrete problems to solve, realistic mock exams, and inspirational quotes to motivate learners.

After 14 days of full focus, I took the CKA exam again. This time, I passed. With a 79% score. I was very proud of myself, so proud that I literally rolled on the floor shouting "I AM A CERTIFIED KUBERNETES ADMINISTRATOR". It was a very joyful moment for me.

I turned to CKAD next and cleared it a week later with an 83% score.

CKS, the crown jewel

It was then time to face CKS, the ultimate challenge for aspiring Kubestronauts. The CKS exam had a certain kingly aura surrounding it. It was viewed as the crown jewel for kubernetes professionals and had the reputation to be the hardest CNCF exam at the time.

Armed with my recent success, I planned the CKS a week after I passed CKAD. But it was soon obvious to me I wasn't ready, so I gave it one more week. Then I took it…. And missed it by 1%. I scored 66%, the passing score was 67%. I was pissed. Again, I made the same mistake as my first CKA attempt: spent too much time on questions I was having trouble with, instead of flagging them for later and moving on. At the end I rushed to the last question when there were 2 minutes remaining. It was about creating a secret with certificate files. I knew how to do it, but did not have time to type the solution. Solving that question would have definitely given me the extra score to pass the exam.

An anecdote about this first CKS attempt. I took the exam on February, Friday 13th 2026. When I told my 8-year-old on Saturday 14th that I missed the exam by 1%, his reaction was:

"Dad, this was to be expected. Friday 13th is a bad luck day. You should have known."

I burst out laughing. To be fair, this thought crossed my mind when I was booking the exam, but I dismissed it and moved ahead. A Kubestronaut wouldn't be superstitious!

Unlike the last time where failure to pass CKA turned me away for months, this time I decided to charge again immediately. I booked another attempt for 4 days later and went back to work. I went back to complete some of the Kodekloud mock exams I had skipped (wrongly) and bought one more killer.sh session to rehearse. Then I took the CKS again. This time, success was the result. I scored 91%. One of my highest scores. Another proud moment. I was officially a Kubestronaut.

Nine months in, the reward

Nine months after I kickstarted the process, the reward was here. And I thought it was totally worth it. I learnt tons and tons of things about kubernetes. I was now able to set up a cluster from scratch using kubeadm, troubleshoot various cluster issues, deploy applications by following best practices, and use various security tools to protect Kubernetes cluster and workloads. I learnt many hows and had answers to many why. When it comes to kubernetes, confidence has replaced apprehension. Confidence rooted in a deep understanding of the internals of the tools, backed with the ability to solve elaborate concrete use cases. It was a journey worth taking.

Riding the momentum

Then I moved on to capitalize on my momentum. I earned CNPA, OTCA, CAPA, one after the other. Then came ICA: Istio Certified Associate. This one I approached with apprehension. I had known about istio almost as long as kubernetes, but I had never really used it in practice, and I had heard scary stories about it. But as I progressed in my preparation, the fear started to dissipate. For some reason, it just resonated with me. I learnt my way into the doc, and by the time I took the exam, I knew where to look for any question. 98%. The highest score I ever had. Another proud moment.

Then came LFCS and CBA. LFCS took me back under the hood of linux, which I had used since engineering school. It was a chance to refresh and go deeper on many aspects that matter for modern cloud native tools. CBA introduced me to Backstage, a tool I ended up wishing every company I had worked for had used. I cleared both without much trouble.

By March 29, 2026, I was holding 15 CNCF certificates. One exam away from Golden Kubestronaut status. The stars were in sight!

The remaining cert was CNPE: Certified Cloud Native Platform Engineer. Before I took on this one, I decided to consolidate and validate everything I learnt so far by building a fully fledged Cloud native platform from scratch. So I rented some VPS from a cloud provider and embarked on this quest. Still on it more than 5 months later.

The most productive stretch of my life

What I retain of this period is how productive I was between mid-December 2025 and mid-March 2026 when I was effectively jobless. These days all looked the same: I would wake up around six o'clock, meditate for a few minutes, do some physical exercise for another few minutes, before the kids woke up. Then I would go back to it once the kids left for school with the goal to learn something new, which essentially consisted in making as much progress as I could on whatever exam I was studying for at the moment. Then I would go out for a walk so I wouldn't be locked in 24 hours a day. I tried to journal every day, mostly about the progress I was making, and go to bed by 10:30 PM. Although I was looking for a new job, I was very happy with how my days were organized. I used an excel file to track my days so I could see progress taking hold and not rely on gut feeling. Soon enough, what started as a skill-consolidation pet project morphed into an application named Klatos, an extension of that excel file, so to speak. I will write about that at some time.

Klatos

That excel file became Klatos — a habit tracker that turns small daily steps into a changed year. It is the first product from Vixoris.

Learn more about Klatos →

Vixoris — Structures that compound.