Several days have passed since this year's 

, providing an opportunity for reflection. 

KubeCon is an exceptional conference, offering a wealth of valuable content.

This year we made sure we arrived early enough to also catch all of the amazing talks in the 

-hosted co-located events happening the day before the main KubeCon event.

Year after year, KubeCon reveals intriguing trends. This year, we observed the rapid integration of AI into cloud-native and 

While many are currently working with AI, the challenge resides in creating a robust DevOps narrative around AI and transitioning projects into production.

This is where Kubernetes and cloud-native technology could offer a solution to these challenges.

 is another trend. It appears that WASM is increasingly popular, with many major projects already using it in production.

Its name can be misleading, as its use extends beyond just web browsers.

Web Assembly appears to be, and increasingly could become, a common compilation target for numerous languages.

This would facilitate smaller binaries, a security sandbox, a shared runtime, and platform-independent packages.

With a really small footprint and startup time this could fit very well into a lot of applications.

Kubernetes on the edge was also something that got a good amount of attention.

 seems promising and definitely something we will dive more into.

Our personal highlight was perhaps the talk from Cloud-native-startupfest, which was called “Fireside Chat with Kelsey Hightower and Alex Polvi, CEO, CoreOS, Inc”.

Amazing insight into a really remarkable journey that gave us a lot of inspiration!

As with the previous year, security remains a crucial topic that received substantial coverage at KubeCon. 

We found the Capture The Flag event hosted by 

 both valuable and entertaining, offering a welcome break from sessions.

Beyond learning, KubeCon is a great place to connect with community members.

We particularly enjoyed meeting both new and old friends at the Nordic Cloud Native Meetup and the Norwegian rooftop lunch!

We're already looking forward to next year!

Most of the sessions was recorded and are available at 

https://www.flickr.com/people/143247548@N03/

https://creativecommons.org/licenses/by-nc/2.0/

#hackathon #kubecon #cloudnativecon #kubernetes #cloud #cncf

Dive into post-KubeCon insights on AI, Web Assembly, Kubernetes on the edge, and more. Discover trends shaping the future! #KubeCon #CloudNative #AI #WebAssembly

Insights from KubeCon 2024: Trends, Highlights & Community Connections

In October 2022, we’ve decided to create a unique brand and website for Enabler that aligns with our values. 

 for just a basic website with information about the company.  So in October we’ve got in contact with absolutely brilliant designers that helped us create new brand for Enabler.

We've collaborated with great designers, 

 from Poland, to create a brand new website design.

, specialised in Design Systems and Artur is 

. They have a lot of experience, and after our initial meeting, we were confident that we wanted to collaborate with them for the upcoming months.

So we started having workshops led by Matt to find out what our values, goals, and purpose are behind what we do. 

After several workshops, discussions, and rounds of feedback, Matt supplied us with ready-to-use 

The Brand Guidelines provide information about colors, typography, and logos.

Meanwhile, Brand Elements include social media profile pictures, cover images, email footers, resume templates, and desktop background images, among others.

And once our brand was ready the next step was to create a new website for Enabler. 

Following several meetings with Artur, he grasped the type of website we desired and crafted a stunning design that incorporated our new fonts, colors, and logo.

The entire branding process took about three months. Our developer, Dominika, then took over and began implementing the new design on the website.

It was important for us to create a responsive and fast website using modern technologies. Here are the technologies we used to create the website:

 is powerful framework for building performant, scalable and maintainable web applications. It allows us to generate static HTML files at build time, which improves our site's performance and reduce hosting costs. It makes the website much quicker, comparing to other solutions.

It has a great solution for optimising images for different devices and screen sizes. 

It offers lazy loading to enhance page load times and priority image loading. This prioritizes the loading of essential images on the page, ensuring they load as quickly as possible for an improved user experience.

Another important solution is the font loading optimization library, next/fonts. It enhances the performance and usability of a webpage by optimizing how fonts are loaded and rendered.

, because it helped us develop our webpage faster, using pre-defined utility classes, that we used to quickly apply styles to HTML. 

We can easily customise these classes by adding our own colors, fonts, and other to the Tailwind config. This allowed us to create a unique design for our website.

Tailwind CSS also supports styling any vanilla HTML that we cannot control, such as content from articles pulled from CMS. 

. This plugin offers a set of prose classes that can be used to apply default styles to headings, blockquotes, links, and more.

Tailwind CSS makes it easy to maintain a consistent, responsive design and user experience throughout website.

 is a headless CMS (Content Management System) that we used on our website. 

It allows us to define custom data models, so our data is organised the way we want, making it easy to work with. 

, as one of the dependencies to retrieve any crops or hotspots present in the Sanity content.

We can specify the width and height to get cropped and resized image according to the wishes of the content editor. 

We can also specify the format or quality to obtain the most optimized images.

Next/image combined with @sanity/image-url:

 to create unique images on our website. 

Midjourney is a generative artificial intelligence program and service. It's created and hosted by Midjourney, Inc., an independent research lab located in San Francisco. Midjourney generates images from natural language descriptions, which are called "prompts."

We are very pleased with the outcome. Hopefully, you will like our new webpages and profile as much as we do!

Transforming Enabler with a fresh brand and website design! Dive into our journey, tech stack, and collaboration with top-notch designers.

Revolutionizing Enabler: Branding & Web Design Journey

Venturing into the world of deploying an MQTT broker in Kubernetes can lead you to some intriguing challenges, especially when compared to the more traditional tasks of serving webpages or APIs

Unlike HTTP-based services, MQTT is served over TCP. Consequently, some common ingress solutions, such as ingress-nginx, do not natively support serving TCP traffic. We'll explore how we could bypass this limitation.


Ensuring secure communication between the MQTT broker and clients is crucial. However, manually creating and managing SSL certificates can be a tedious process. We'll demonstrate an automated method for managing SSL certificates, making your MQTT communication secure and worry-free

First things first, let's generate the certificate we want to use. The "de facto standard" for this task is cert-manager, and we'll use a cert-manager-generated certificate in the same way we do with other ingress-generated certificates. This ensures the certificate stays up-to-date.

As long as your DNS points to the Ingress controller's load balancer for the specified host making it possible for cert-manager to validate your host, you should have a secret containing the certificate in your cluster.

Now, it's time to deploy an MQTT broker. Although we often prefer cloud-native brokers like EMQX, we've opted for Mosquitto in this example due to its simplicity.

We'll refer to the generated secret when specifying the certificate location in the config. 


Keep in mind that the example above allows anonymous access to the broker. In a production environment, you'll need to secure your endpoint with an ACL, password list, or similar method and disable anonymous access.

After deploying the components mentioned above, you should have a working MQTT broker with a certificate securing it. However, it's not yet accessible from outside since TCP traffic isn't routed by ingress-nginx.

To overcome this, we can leverage a lesser-known feature in ingress-nginx that allows routing specific ports to TCP services within the cluster. Note that we're not using any host headers here, so any request to any host pointing to the ingress service will be routed on the specified port.

https://kubernetes.github.io/ingress-nginx/user-guide/exposing-tcp-udp-services/

To do this we will use a configmap called tcp-services to keep track of routed ports.

The last part is to tell ingess-nginx to read the configmap and allow port 8883 into to load balancer. 


Add port 8883 to the ingress load balancer ports. 

Assuming you have a service named "mosquitto-mqtts" in the "mosquitto" namespace, this should route the port to the broker. Now, you're all set with a fully functioning Mosquitto MQTT broker with encrypted communication in Kubernetes. Enjoy!

Deploying Mosquitto in Kubernetes? Learn to bypass TCP traffic challenges, automate SSL certs, and expose ports for secure MQTT communication effortlessly.

Mosquitto MQTT broker in Kubernetes

Is it necessary for your Kubernetes API to be publicly exposed to the internet? From our observations, the Kubernetes API is frequently accessible online due to using default settings when creating a cluster or because there were limited options at for making it private at the time the cluster was created. While you still need the appropriate credentials to access it, it's important to evaluate if public availability is truly required.


I recently discovered that this topic is also covered in OWASP's Kubernetes Security Cheat Sheet. The cheat sheet provides valuable insights and guidelines for enhancing the security of your Kubernetes environment. 

At the moment there are two primary methods for restricting access to the Kubernetes API server in Azure Kubernetes Services:

https://learn.microsoft.com/en-us/azure/aks/api-server-authorized-ip-ranges

Microsoft recommends this approach as a simple solution for limiting access to the API.

https://learn.microsoft.com/en-us/azure/aks/private-clusters

This option involves creating a private network in Azure, where your cluster is placed. Although it introduces additional complexity, it also offers benefits such as allowing Kubernetes to communicate internally with other resources within the same private network.

It is crucial to assess the available alternatives and make an informed decision.

Each use case is unique, and a publicly accessible cluster might be entirely acceptable. However, it is crucial to assess the available alternatives and make an informed decision.

Secure your Kubernetes API: Evaluate public exposure. Explore methods like Authorized IP Ranges & Private Clusters for enhanced security

Securing Your Kubernetes API

Her ønsker vi å dykke ned i teamer som vi brenner for, som for eksempel DevOps, cloud native teknologier og bedriftsutvikling.