Closed BlueIcarus closed 1 year ago
stefanprodan
commented
4 years ago Is Flagger able to create the initial primary ConfigMap if you create a new canary/deployment with a large config? If so then I think this hits the max etcd limit due to the kubectl annotation, as it duplicates the content in kubectl.kubernetes.io/last-applied-configuration.
BlueIcarus
commented
4 years ago Flagger creates the initial primary configmap but that configmap doesn't contain any binaryData object (thats the third code section I posted in my initial item). Does this related to the last-applied-configuration and etcd you mentioned or might there be a other cause of this issue? If this is the issue it might be a smart idea to update the docs to hold the remark that there is a limit to this (and if possible even specify the limit)
bkumar73
commented
3 years ago @BlueIcarus were you able to fix this issue?
BlueIcarus
commented
3 years ago @bkumar73 No unfortunately not. As posted by @stefanprodan, this appears to be related to the mac ETCD limit. I have decided against changing any ETCD configuration.
Please note: I have not validated the comments I'm about to describe below!!! You might be able to change the ETCD System Limits as described here: https://etcd.io/docs/v3.3/dev-guide/limit/#:~:text=The%20default%20storage%20size%20limit,the%20configured%20value%20exceeds%20it.
This is at your own risk and I have not tested this! If you however change this and it works after your changes, I hope you post an update here so everyone can benefit from your successes! And if it indeed works, I will create a PR to update the documentation for those that might have the same issue
bkumar73
commented
3 years ago @BlueIcarus : Thanks for your quick response. Currently, I am using Managed Kubernetes cluster, Hence it will little difficult to implement this solution.
I have been having some issues with some ConfigMaps not being copied properly from 'default' to 'primary'. I have been looking over the configuration I have and I have checked the differences between those that work and those that don't work. It seems to me that there might be a issue with larger files in the ConfigMaps.
The logging of flagger doesn't mention any issues with the copy action:
The configmap (a example file) is use to test:
Below the content of the primary configmap file:
I can't seem to find any other issue that looks related to this task. As I mentioned before this is only a example configmap but it can be used to reproduce the issue.