Hey everyone, I'm fairly new to Kubernetes and working on a project that revolves around custom resources corresponding to cloud resources. I want to clarify my situation: I have three custom resources labeled A, B, and X. A and B are related as parent and child, meaning when I create A, B is created automatically. On the other hand, X is an independent resource that represents a request to join a group. X has several fields, but the key ones are 'groupId' (linking back to resource A) and 'joinerId' (the ID of the joining resource).
I'm facing issues with concurrency since the X resources can be created at any time. This raises questions about how to safely write into the status/spec of B (or A) without risking conflicts. I considered using locks in resource A to manage this, but I'm worried it might lead to memory leaks. Another option I thought of was querying B to pull all X resources that link back to it, but this seems inefficient, especially with many X resources being created. I'm feeling stuck and concerned about the implications for future development. Any insights would be greatly appreciated!
3 Answers
Reconciliation in Kubernetes is typically eventually consistent. This means that while one reconciliation might perform suboptimal actions, the next one will fix those discrepancies. If consistency is critical for your application, maybe your CRDs need a redesign to ensure they better reflect your use case.
It sounds like you might be dealing with an XY problem here. If A, B, and X are all instances of the same Custom Resource Definition (CRD), I think that’s where your challenges might be stemming from. Considering that X should be a separate CRD could clear things up a bit. Also, keep in mind that etcd provides sequential consistency, so you shouldn't face race conditions as long as everything is within the quorum.
Could you explain what an XY problem is? I'm not quite familiar with it.
No worries! I can repost with the details about the actual issue instead of the side problems.
Honestly, your approach seems a bit convoluted. Make sure you're clear on what you're trying to achieve—if the relationships between A, B, and X aren't well defined, it can lead to confusion. It might even be worth exploring if a relational database could fit your needs better, as it seems like this might not be the best use case for CRDs.
Thanks for the feedback! I’ll rethink my strategy moving forward.
Thanks for the advice! I’ll make sure to include more concrete details next time.