Support for configuring Gitea from the main container #632
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: lunny/helm-chart#632
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Hey everyone!
I was trying to install Gitea on a k8s cluster with Istio injection enabled and using a MySQL database which is hosted inside the cluster itself. Istio adds a sidecar to Pods which handle all the network traffic, handling transparent mutual TLS communication and more, but it has the side effect of creating issues when trying in-cluster network communication from init containers if mTLS is required (plus, MySQL is a server-first protocol so there are a few other issues).
Since the Chart uses a init container to configure Gitea, interacting with the database, I found no way to have it working when Istio is enforcing mTLS to the MySQL database and I had to modify the chart to run
/usr/sbin/configure_gitea.shinside the main container before the main entrypoint.Wanted to ask if I can provide a pull request for this, or if this issue was already analyzed and there's an alternative solution?
Hi. Thanks for reaching out. There are known issues with using this Helm Chart in pair with Istio. I've filed an issue to rethink the init container usage (#332). Unfortunately, none of us maintainers had enough time yet to redesign the init container usage. It comes with a necessary redesign of the app.ini creation and updating. The app.ini creation needs to be migrated out of the init container phase first, so that Gitea can properly start. Then it can be fine tuned and customized. There are 2 open WIP PRs regarding app.ini redesign: #450 and #544.
If you want to help redesign the init container usage, you are very welcome.
Actually, I found out an existing solution for this, which solves the problem without requiring any change to the Gitea Helm chart.
Starting from Kubernetes 1.28 a new feature gate was introduced, called
SidecarContainers, which is now in beta and enabeld by default in 1.29 version. When enabled, sidecar containers can be scheduled as init containers. This is already supported by Istio under an env variable for now.I tested it out and it works without issues,
configure-giteacan run as init container because Istio sidecar is already available.That's a neat way. Thanks for sharing and glad you found a solution.
(Moving away from init containers will still be done at some point. Istio was not the main reason for that. 🙂)
Do you mind adding your solution to the docs? I guess there will be others having similar issues in the future.
@NotAndD I assume you refer to this Istio blog post and this Kubernetes feature gate documentation?