previously @jrgd@lemm.ee, @jrgd@kbin.social

Lemmy.zip

  • 0 Posts
  • 3 Comments
Joined 10 months ago
cake
Cake day: June 3rd, 2025

help-circle
  • jrgd@lemmy.ziptoSelfhosted@lemmy.worldAuthentik Helm woes
    link
    fedilink
    English
    arrow-up
    2
    ·
    3 days ago

    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.


  • jrgd@lemmy.ziptoSelfhosted@lemmy.worldAuthentik Helm woes
    link
    fedilink
    English
    arrow-up
    2
    ·
    3 days ago

    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.


  • jrgd@lemmy.ziptoSelfhosted@lemmy.worldAuthentik Helm woes
    link
    fedilink
    English
    arrow-up
    4
    ·
    4 days ago

    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.