search

nextcloud / helm

A community maintained helm chart for deploying Nextcloud on Kubernetes.
GNU Affero General Public License v3.0
338 stars 268 forks source link

InitContainer checks incompatible with Istio Service Mesh #383

Open brandtkeller opened 1 year ago

brandtkeller commented 1 year ago

Describe your Issue

I understand this is a niche problem - Looking at #42 I can see why these checks are in place.

Given that, I still believe it would be valuable to have the initContainer have a conditional value in order for the postgresql-isready checks to be disabled when required.

My workflow is to deploy nextcloud on a cluster with Istio service mesh. I prefer that all of my workloads use mTLS encryption for traffic - which does not work well with the sidecar container strategy unfortunately.

My planned execution is to use Flux to deploy postgresql as a release separately of nextcloud in the same namespace and then have the nextcloud release depend on the postgresql release such that postgresql will always be happy before nextcloud installs/restarts.

Logs and Errors

Given that the sidecar for istio doesn't exist during initContainer runtime - the postgresql-isready cannot connect to the postgresql pods due to strict mTLS encryption.

Describe your Environment

Kubernetes 1.26.x

jessebot commented 1 year ago

Sorry for the long delay, but thank you for raising this issue!

A quick question I have is: can we instead implement a feature to utilize mTLS? Would that be acceptable?

jessebot commented 1 year ago

Wanted to follow up and mention that I'd also be happy to review a PR to disable that init container entirely, but wanted to know if adding TLS variables/mount points would help any.