Skip to content

[backend] kubernetes: fix secret size limitation #29678

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

Merged
merged 8 commits into from
Aug 25, 2023

Conversation

k0da
Copy link
Contributor

@k0da k0da commented Sep 30, 2021

By now kubernetes backend could hold up to defaultETCDSize gzipped data
(which is 1-1.5Mb). This doesn't scale for larger states.

This commit implements spliting data across multiple secrets bound by
the same Secret labels. This practically removes etcd value size
limitation and allows backend to scale across multiple secrets.

This also takes care of cases when state needs to be shrinked. In such
case code will cleanup unneeded secrets.

Signed-off-by: Dinar Valeev dinar.valeev@absa.africa

@k0da k0da force-pushed the kubernetes_multipart branch 2 times, most recently from 9930bf6 to cfa8df9 Compare October 8, 2021 07:01
@Skaronator
Copy link

This is basically a similar fix as #28838, but for the kubernetes state file.

@hashicorp-cla
Copy link

hashicorp-cla commented Mar 12, 2022

CLA assistant check
All committers have signed the CLA.

@crw
Copy link
Contributor

crw commented May 24, 2022

Thanks for this submission! I will raise this with the internal maintainers of the kubernetes backend. Although I cannot commit to having this PR reviewed at this time, we acknowledge your contribution and appreciate it! Thanks again for the submission!

@Bernix01
Copy link

Just making noise to this PR, is this a ready to go?

Copy link
Member

@alexsomesan alexsomesan left a comment

Choose a reason for hiding this comment

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

It was a bit difficult to comprehend certain parts of this change so I left some spot questions that might hopefully clarify it.

Also, a more general question: is there potential for conflict if more than one terraform workspace is stored in the same K8s namespace?

},
},
}
secret, err = c.kubernetesSecretClient.Create(ctx, secret, metav1.CreateOptions{})
Copy link
Member

Choose a reason for hiding this comment

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

AFAIK the Create call translates into a POST HTTP method. How does this behave when the Secret for the chunk already exists?

Copy link
Contributor

@jrhouston jrhouston Feb 2, 2023

Choose a reason for hiding this comment

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

The logic above this checks if the secret already exists or not and only calls create if it does not already exist. We could however reformulate this as a single patch call instead. This is just logic that was already present for the single secret backend, it has just been shuffled around in this PR.

@jrhouston jrhouston force-pushed the kubernetes_multipart branch from bad6c66 to 7f1188e Compare February 2, 2023 04:24
@jrhouston
Copy link
Contributor

jrhouston commented Feb 2, 2023

Also, a more general question: is there potential for conflict if more than one terraform workspace is stored in the same K8s namespace?

The purpose of the secret_suffix attribute here is so you can store multiple terraform states in the same namespace and the secrets will get a different name. You would cause problems if you deliberately used the same prefix across more than one terraform config.

Copy link
Member

@alexsomesan alexsomesan left a comment

Choose a reason for hiding this comment

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

Thanks for the fixes @jrhouston!
Looks good!

@Bobonium
Copy link

Was there a specific reason why this was not merged and released after @alexsomesan approved it in february? This feature would still be very much appreciated.

@crw
Copy link
Contributor

crw commented Aug 24, 2023

Looks like it got missed. I will add it to the triage queue. Thanks!

k0da and others added 7 commits August 25, 2023 11:54
By now kubernetes backend could hold up to defaultETCDSize gzipped data
(which is 1-1.5Mb). This doesn't scale for larger states.

This commit implements spliting data across multiple secrets bound by
the same Secret labels. This practically removes etcd value size
limitation and allows backend to scale across multiple secrets.

This also takes care of cases when state needs to be shrinked. In such
case code will cleanup unneeded secrets

Signed-off-by: Dinar Valeev <dinar.valeev@absa.africa>
- Remove unneeded function
- Consistently use "chunk" as the unit
- Sort the secret response by the index
- rename etcdDefaultSize to defaultChunkSize

Verified

This commit was signed with the committer’s verified signature.
bflad Brian Flad

Verified

This commit was signed with the committer’s verified signature.
bflad Brian Flad

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
@jrhouston jrhouston force-pushed the kubernetes_multipart branch from dd84fa3 to 119a8c0 Compare August 25, 2023 16:02
@kmoe
Copy link
Member

kmoe commented Aug 25, 2023

Thanks for your patience, everyone!

@kmoe kmoe merged commit 200ff93 into hashicorp:main Aug 25, 2023
@github-actions
Copy link
Contributor

Reminder for the merging maintainer: if this is a user-visible change, please update the changelog on the appropriate release branch.

@sftim
Copy link

sftim commented Sep 28, 2023

When the data are gzip encoded, what I'd expect to find is that each Secret holds a valid gzip stream. Concatenating these also produces a gzip stream that you can uncompress and deserialize.

Is that how it works?

@sftim
Copy link

sftim commented Sep 28, 2023

💭 I wonder whether and how we provide atomic updates when there are multiple Secrets

Copy link
Contributor

github-actions bot commented Dec 8, 2023

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Dec 8, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet