Optimizing Git Clones at the Repository Level for ImageUpdateAutomation

[Ishii-Taiki]

Target Component

• ImageUpdateAutomation, (source-controller)

Summary

I propose enhancing the ImageUpdateAutomation controller to support Git repository-level cloning, reducing the frequency and redundancy of Git clone operations. This optimization aims to significantly lower data transfer costs associated with AWS NAT Gateways in environments where multiple ImageUpdateAutomation resources reference the same Git repository. I seek approval to proceed with this implementation and welcome feedback on the proposed approach. I am prepared to develop and contribute this feature myself.

Proposal Details

I'd like to propose a new option in ImageUpdateAutomation that allows cloning at the Git repository level, reducing the frequency of Git clone operations. I would prefer to discuss the architecture for implementing this change in this discussion thread after receiving approval for the initiative. I plan to implement this feature myself.

Motivation

In our AWS EKS cluster, we are considering expanding the use of ImageUpdateAutomation. However, we have identified that this expansion significantly increases NAT Gateway (NAT GW) costs. The root cause appears to be the Git clone operation performed during each reconcile by every ImageUpdateAutomation resource.

Even when referencing the same branch and commit of a Git repository, each ImageUpdateAutomation resource triggers a separate Git clone operation, which increases data transfer costs. Reducing the spec.interval for faster reconciles further amplifies this issue, effectively doubling the traffic and costs.

We observed that by halving the spec.interval, the traffic and associated costs doubled. This behavior discourages us from shortening the spec.interval for a more efficient update process and limits our broader use of ImageUpdateAutomation.

The attached graph illustrates this behavior:

• The left side of the graph shows the network traffic when the spec.interval is set to n, resulting in relatively low traffic.
• The right side shows the impact of halving the spec.interval to n/2, where the traffic and associated costs increase significantly.

The proposed solution would change the current reconciliation model from n * m * o to 1 * m * (repo-level git clone frequency), where:

• n = Number of ImageUpdateAutomation resources,
• m = Data transfer per Git clone operation,
• o = Average spec.interval for each ImageUpdateAutomation resource.

By reconciling at the repository level, we expect to reduce the overall data transfer to only one Git clone per repository, regardless of the number of ImageUpdateAutomation resources, thereby significantly lowering NAT Gateway costs.

Expected Benefits

• Reduced data transfer and NAT Gateway costs
• More efficient use of ImageUpdateAutomation with a shorter spec.interval.
• Improved scalability for users managing multiple ImageUpdateAutomation resources referencing the same Git repository.

Offer for Collaboration

While I cannot provide specific numerical values at this time, I have an environment set up where we can conduct testing to validate the effectiveness of this proposed feature. I am willing to collaborate and provide testing data to demonstrate the reduction in network traffic that this change could achieve.

I look forward to discussing the implementation details here and am ready to contribute to its development.

[Ishii-Taiki]

I’m closing this issue as I received helpful tips from @kingdonb on Slack.
Thank you, kingdonb!
https://cloud-native.slack.com/archives/CLAJ40HV3/p1726748900372779