Enig eller uenig, noe du mener vi har glemt? Vi er alltid interessert i å delta i engasjerende diskusjoner om teknologitrender og alt innenfor plattform. Ta gjerne kontakt med oss.

Ta kontakt

Tilbakemelding?

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

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

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

One of the most challenging and interesting aspects of working with platforms is staying ahead of the countless tools and techniques available. 

 collection alone is vast, and this image only represents a fraction of the technologies and methods we encounter daily:

Given our fortunate position of working with multiple platforms for various customers across multiple business domains, we believed sharing our internal 

 collects our findings and experiences from diverse projects and internal testing of new tools. It draws inspiration from 

. However, unlike it's counterpart, which releases updates several times a year, our radar is continuously updated.

For those curious about a "blip's" history, you can simply click on it to explore its evolution.

By sharing our knowledge and experience, we hope to inspire you to explore new technologies, experiment with them, and engage in open discussions. 

Our continuously updated Tech Radar offers insights on the latest tools and technologies to help you stay ahead in the Cloud Native Landscape.

Tech Radar: Enabling Insightful Technology Decisions

 for uptime monitoring. However, it has two main drawbacks: it doesn't scale well with numerous probes, and it's not suitable for a GitOps scenario due to its heavy usage of GUI for configuring probes

Our goal is to add probes automatically as part of the GitOps setup when deploying new applications that need monitoring. Recently, we tested 

Deploying Application Insights Infrastructure

To start, you need to deploy the Application Insights infrastructure if you don't already have one. This requires the 

 for Crossplane. We assume you're already using Crossplane and are familiar with its operation.

When the provider is deployed you can provision an Application Insight instance, a Log Analytics Workspace and a resource group:

If Application Insights isn't provisioned, it's likely because the Azure Resource Providers "microsoft.insights" and "Microsoft.OperationalInsights" aren't registered. You can check this under your subscription in 

Azure → Settings → Resource providers

You could skip the Log Analytics workspace. This would result in a "Classic Application Insights" that's still functional, but it's soon to be a deprecated solution from Microsoft.

More about the deprecated Application Insights here: 

Once everything is provisioned, you can start adding probes.

 is up every 300 seconds (the default interval).

To make effective use of the probes, you should add alerts to appropriate channels. We prefer using collaboration tools like Slack or Teams to collect alerts and collaborate on them as a team.

The GitOps experience with this setup is excellent and precisely what we're aiming for. However, one significant drawback is the pricing. As the number of probes increases, the cost can become substantial compared to alternative solutions.

The example above is for 50 endpoints checked every 5 minutes from one geolocation. If you want to check more endpoints, more frequently, and from multiple geolocations simultaneously, it can quickly become expensive.

For a smaller number of probes, or if you already use Azure and don't want to introduce new third-party services, Azure Monitor Availability can be a good choice. However, we are still looking for other solutions suitable for a GitOps situation with a larger number of probes.

Tech Radar: Enabling Insightful Technology Decisions

Tech Radar: Enabling Insightful Technology Decisions

Our Initiative

The Tech Radar

Conclusion and Invitation

Insights from KubeCon 2024: Trends, Highlights & Community Connections

Securing Your Kubernetes API

Mosquitto MQTT broker in Kubernetes