jrgd

From the project’s site, an eBlockerOS-powered device allegedly uses ARP spoofing to hijack as the default gateway and serving as a second hop in the internal network. Behaving as an NGFW can have some benefits over just DNS filtering that services like PiHole achieve. Things the project lists it is capable of include global VPN tunneling, DNS request masking, parental controls, content blocking.

It could be technically better than just PiHole (assuming the project is legitimate), but I will argue so would a router running OpenWRT or similar. Depending on the SBC used with it, I would be concerned with network throughput performance (both Ethernet link speed limits and CPU utilization from certain services). Additionally, its configuration would mean it being a full second-hop device on the local network, which may cause its own category of issues. The main use case I could see for this project is if you’re completely stuck with your ISP’s router and cannot touch much about it.

Coming back and checking the values file posted. Not sure why your authentik block won’t get used in your values file. Your current issue of non-starting is likely the Authentik server container starting successfully, but failing liveness while waiting for the worker container(s) that is definitely not spooling up with your current configuration.

Something to denote about Authentik itself that won’t be well-explained by the quickstart for the Helm chart itself is that Authentik is split into two containers: server and worker. For most environment variabless and mounted secrets, both the server and worker definitions should have them applied. The chart tends to handle most of the essential shared stuff in the authentik block to prevent the duplication, but secrets will likely need to be mounted for both volumes if using file or env references in the shared config, as well as most env overrides will need to be applied for both.

In my case I’m running an external Postgres DB and external cache plus a handful of other settings. As such, I have a decently sized values file. All of the env vars I was looking for in my case are provided in the chart, so I didn’t need to set any directly, but just through their counterparts in the values file.

I don’t use ArgoCD in my case, so I couldn’t really say if it would affect your deployment strategy in any way.

When I did my authentik setup through helm chart a while back, the only real problems I had were with learning blueprints and not so much with getting Authentik to do its thing.

The main things you should be checking given a liveliness probe failure is kubectl -n <namespace> describe pod <podname> to check the reason for failure. Additionally, kubectl logs -p -n <namespace> <podname> [container]. Will get you logs of the last run of the pod that has already failed, rather than the current run that may be soon to fail. Those two commands should point you pretty directly where your chart config has gone wrong. I can likely help as well if you are unsure what you are looking at.

Additionally, once you get things working, please go back and usw secrets properly with the chart. Authentik lets you sub many values for env vars or files, which combined with mounting secrets is how you can use them.