You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Per comment on #1495, in order to support mTLS for HTTP in Kubernetes with appropriate health probing, the ideal option seems to be to call rqlite CLI inside the container to run a readiness check. However this isn't currently possible, because this command never terminates:
echo .ready | rqlite [...]
From Kubernetes' perspective, the cleanest solution would be a noninteractive command that exits with status 0 on success (ready), and non-zero on failure (not ready). And perhaps that would be easy for rqlite as well, just to implement an additional single-purpose command line option?
A more flexible option would be to update rqlite to support arbitrary commands non-interactively. This would be analogous to the sqlite3 CLI's ability to receive SQL statements in the second optional non-flag positional command line argument. The SQL is run, and the process terminates.
While more generally useful for rqlite at large, this is actually slightly less clean for the K8s side, because if I called rqlite [...] .ready , if the command doesn't indicate readiness status via exit code, I would need to also rely on a shell to pipe rqlite's output to grep inside the container, whereas a dedicated readiness check flag in the rqlite CLI (that works as I first described above) would only depend on the presence of rqlite (so compatible with stripped down distroless containers).
But ultimately I can make either work given the current container that includes busybox.
The text was updated successfully, but these errors were encountered:
Per comment on #1495, in order to support mTLS for HTTP in Kubernetes with appropriate health probing, the ideal option seems to be to call
rqlite
CLI inside the container to run a readiness check. However this isn't currently possible, because this command never terminates:From Kubernetes' perspective, the cleanest solution would be a noninteractive command that exits with status 0 on success (ready), and non-zero on failure (not ready). And perhaps that would be easy for rqlite as well, just to implement an additional single-purpose command line option?
A more flexible option would be to update rqlite to support arbitrary commands non-interactively. This would be analogous to the
sqlite3
CLI's ability to receive SQL statements in the second optional non-flag positional command line argument. The SQL is run, and the process terminates.While more generally useful for rqlite at large, this is actually slightly less clean for the K8s side, because if I called
rqlite [...] .ready
, if the command doesn't indicate readiness status via exit code, I would need to also rely on a shell to pipe rqlite's output to grep inside the container, whereas a dedicated readiness check flag in the rqlite CLI (that works as I first described above) would only depend on the presence of rqlite (so compatible with stripped down distroless containers).But ultimately I can make either work given the current container that includes busybox.
The text was updated successfully, but these errors were encountered: