Skip to content

Conversation

@oommoo
Copy link

@oommoo oommoo commented Nov 7, 2025

In our environment we are using rke2 for kubernetes and istio for the service mesh. Given that the wait-for-db container is defined as an initContainer, it runs prior to the istio-proxy, thus can not connect to the database.

wait-for-db-before-istio-proxy

This proposed change moves the container element to include the wait-for-db definition and adds an empty list for initContainers. This change, along with an istio setting of holdApplicationUntilProxyStarts=true, allows the istio-proxy to execute, setting up the required networking to access the database.

istio-proxy-before-check-db

@oommoo oommoo requested a review from a team as a code owner November 7, 2025 20:29
@changeset-bot
Copy link

changeset-bot bot commented Nov 7, 2025

⚠️ No Changeset found

Latest commit: d0f4b15

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

Copy link
Member

@oliverguenther oliverguenther left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We use the check-db-ready to block spawning the main application container, which is not guaranteed if they are running as a multi-container pod. In my understanding, they will both be started in parallel, which is not what we want.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

4 participants