-
Notifications
You must be signed in to change notification settings - Fork 661
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Secret not yet active when deploying with Helm #1518
Labels
Comments
This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback. |
Due to the lack of activity in the last 7 days since it was marked as "stale", we proceed to close this Issue. Do not hesitate to reopen it later if necessary. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi there,
firstly I want to mention that my issue is more a discussion / question than a bug report (I think so at least):
We deploy all our applications with Helm and we manage our secrets inside our repository with sealed-secrets. Therefore we create them lcoally with the kubeseal command in such a way that they are part of the Helm chart of an application that we want to deploy later on.
Our applications get the secret values then injected as env variables, which are part of the deployment (and denoted in the Helm deployment.yaml template).
When we deploy such an application with Helm, the order of resource creation is correct, so it firstly deploys the (sealed-)secrets and then the deployment Pods. This worked quite good for ~1 year.
Now we noticed however, that there is an issue: When we want to deploy e.g. an updated secret (also with a new application version, which means that our Pods are also newly deployed), some new created Pods get the old secret value and some Pods get the new secret value.
I think that we also saw the issue: It seems like that the Secret is not yet in "Active" state when our first (new) Pods are starting up, which means that they get the old value, and at some point of time the (updated) Secret is ready, so the Pods that are started after this point of time get also the correct new Secret value.
At least that's what we saw, but this might also be a wrong analysis. So my first question: Does that sound plausible? And/or are you aware of this issue? I googled for this issue, but didn't found anything to suggest that people faced a similar issue... so I am not quite sure if we are just doing something completly wrong....
I am not a Helm expert, but after some recherches it seems to me that Helm does indeed not wait till the resources are really ready in the deploy process. So I am wondering what we could do to solve this issue properly? (Of course we could just deploy twice, but this is more a workraound for me). At a glance, I see two options:
Best regards
Clemens
The text was updated successfully, but these errors were encountered: