Sometimes you need your Kubernetes workloads to interact with the underlying host OS, this can be for many reasons but a few common scenarios include:
Monitoring agents that need to read metrics from the host Tools that need to access the underlying container runtime Access to the host network or storage Amending the configuration on the host Installing additional software or agents on the host For Linux hosts, this is fairly straightforward using a privileged daemonset on these nodes which can then access these host resources, but privileged containers aren’t an option for Windows nodes.
Back in the mists of time (otherwise known as 2018), I wrote a post called Azure Container Hosting Demystified which looked at the different container hosting options in Azure, what they are and why you might use them. Four years have passed since I wrote that article. Things have moved on a lot, so it’s time for an updated version.
If you have container workloads you want to host in Azure, then there are many different options for doing that, and it can be pretty confusing trying to pick out which one is right for your project.
Azure Container Apps were recently announced at Microsoft Ignite, let’s take a look at what they are, how they work and why you might, or might not, want to use them.
