Running Home Assistant on Kubernetes

Running Home Assistant on Kubernetes. It is about time to put your IoT devices under control. Everything runs off the cloud on my on-premise Kubernetes. Clean and secure.

This blog will not cover what Home Assistant is or how Kubernetes works. I assume you already have that covered.

Separate network traffic for IoT devices

I created a separate VLAN just for IoT devices on my OpenWRT. Some things to notice about this VLAN.

  • A separate AP exists for devices communicating over WiFi.
  • This VLAN does have access neither to other networks nor to the Internet. So no IoT device will be able to phone home. And most probably you cannot use the official Apps.
  • Kubernets has a dedicated Nginx Ingress Controller listening in this VLAN, opposite to the Traefik Ingress Controller which listens in the default network.
  • The host running Kubernetes does have a network connection in both VLANs (optional).

If you would like to create VLANs but don’t know how to start I highly recommend watching Mark’s great video about VLANs in OpenWrt 21. It will give you a head start.

Use K3s lightweight Kubernetes distribution for IoT

Although there are many Kubernetes distributions to choose from, I have picked K3s.

It is a lightweight Kubernetes and it is proven to work on a bunch of inexpensive unavailable Raspberry Pi4s running in a basement just like Jeff’s Pi Dramble. Make sure to check him out, it is unbelievable. 🙂

The Deployment problem of Home Assistant

There are a couple of supported ways of installing Home Assistant. Unfortunately Kubernetes is not among them. I do not blame them. Probably it simply does not worth the effort to support it, because people using Home Assistant is already a niche market, even more people running Kubernetes at home.

There are 4 options to install it.

  • Home Assistant Operating System – their own operating system based on Docker (no go)
  • Home Assistant Container – A container image containing only the core of Home Assistant (we’ll use this)
  • Home Assistant Supervised – “This way of running Home Assistant will require the most of you. It also has strict requirements you need to follow.” (still requires Docker’s socket – no go)
  • Home Assistant Core – Same as Home Assistant Container but without the container (no go)

The biggest drawback of using their container image is that there will be no “Addons store” feature. And you will need to find the necessary howtos in forums, github issues, etc.

So I will rely on their container image but what about deployment descriptions?

I cannot really use their docker-compose.yml in Kubernetes for other purposes than as a base for creating my own manifests.

There were Helm charts available for some time but at the time of writing this article, none of them are maintained anymore but at least they are better source for creating something new than using the docker-compose YMLs. I decided to roll my own version of manifest and keeping things as simple as possible.

Installing Home Assistant with Kustomize

So I have the official container image but I will need services other than the plain Core of Home Assistant. I need the following functionalities.

  • Home Assistant itself. You can grab the Kubernetes manifest from abalage/home-assistant-k8s.
  • MQTT support (Mosquitto) which is a frequently required integration interface for lots of IoT devices. You can download the Kubernetes manifest from abalage/mosquitto-mqtt-k8s.
  • Nginx Ingress Controller to expose HTTP(s) and MQTT’s TCP port 1883 (later one is not HTTP protocol)
  • MetalLB for acquiring an externally addressable IP address for Home Assistant’s service (LoadBalancer)

Like I mentioned before the Helm charts are outdated and I needed some customization anyway,  hence I use Kustomize to get all the dependencies properly configured and patched to fit my network environment.

You do not need to individually download the manifests. Just check out the GitHub project abalage/Home-Assistant-on-Kubernetes which contains everything you need to start.

Make sure you edit `kustomization.yaml` to fit to your environment. Check out the README for details.

Now you can run your own Home Assistant on Kubernetes.

What do you think? Isn’t it awesome? 🙂

Simplified guide to logging Containers to Elasticsearch in 2020 (with syslog-ng)

A simplified guide to logging Docker to Elasticsearch. Although there are many tutorials about how to ship Containers logs to Elasticsearch, this one is different from all as it uses syslog-ng. It also works with Podman!

Update: I moved the chapters about parsing and visualizing NGINX / Apache access logs in Kibana into a dedicated post / github repo.

Update 2: This post has been refactored and simplified to be compatible with Elasticsearch ECS and make it easier to implement. Compatible with Elasticsearch 7.x.

Update 3 (2020): Add support both for Docker and Podman. Improved readability. Continue reading Simplified guide to logging Containers to Elasticsearch in 2020 (with syslog-ng)

Visualizing Fail2ban logs in Kibana

In the last post I wrote about how you can create a central syslog server. This time I will show you how you can use syslog-ng to parse fail2ban log messages, enrich it with GeoIP metadata and send into Elasticsearch. You can even visualizing Fail2ban logs in Kibana to see where the failed login attempts are coming from.

Update: This post has been reviewed and all Fail2ban and GeoIP related contents have been merged here from the previous post. Look no further, you will find everything you need here. Note that this guide requires Elasticsearch 7.x.

Continue reading Visualizing Fail2ban logs in Kibana

Creating a central syslog server

Your home network might already contain some devices or systems like a home server, a WiFi router, a media player, or home automation system. It is a best practice creating a central syslog server and storing logs of various sources in one place.

Update: The fail2ban and GeoIP related contents have been merged into post visualizing Fail2ban logs in Kibana.

This post will cover the basics. Creating a central log server and receiving logs from an OpenWRT device. Please note that you can do many more. See the other posts I created in this subject.

Continue reading Creating a central syslog server

Docker failed to restart after upgrade

I already had plans to write about Docker. However a recent system update caused issues and Docker failed to restart. This service outage made me think and write about such a typical maintenance task.


Docker logo upside downI know that I created the issue at the first place. However I could fix it and I will show you how I did it and how can I avoid that in the future.

Continue reading Docker failed to restart after upgrade

Mounting NFS exports by using autofs

When I created a central file sever, I mentioned that some of the problems with the solution are yet to be resolved.

autofs better than manual

  1. YaST created an import rule in file /etc/fstab, which is the de-facto place for storing such information. Its content and the mounts are usually static in server environments. On most client (in term of using an export of an NFS server) the network connectivity rarely or never changes in traditional environments.
    However in case of mobile devices like on laptops, the network state could vary a lot. It can be offline, or on WiFi, or on wired connection, maybe using VPNs. We need much more flexibility than a mostly static file.
  2. Users would like to mount exports on their own. The system should be as transparent as possible to the end users.

Lucky for us, mounting NFS exports by using autofs service help us and gives the following advantages too. Continue reading Mounting NFS exports by using autofs